widl could generate 'implementation' source file based on some input IDL with something like coclasses desribing implemented objects. This source file could define all vtbls, forward shared functions, maybe even default `IUnknown`-alike implementation or class factories. (It would probably also need to generate a header file that the rest of module would use to access it, or the whole thing could just be a header). Anyway, I'm not sure, just throwing another idea for a consideration.
I thought about something like that also, although never really got to it, as I thought it would also be interesting to make mock class creation easier for testing. However I ended up with the idea that it wouldn't be very flexible to have it generate everything, and that it would add annoying indirection or hide some details.
For instance with this approach here, I find it convenient that it allows you to selectively replace functions with generated ones through fine-grained macros. It can be useful for some exotic or specific use cases, COM aggregation for instance (although that could also be supported). It also only requires a couple of naming conventions in the implementation structs, but doesn't add any kind of indirection there, you still see all the details of the implementation, only the actual boiler place functions are hidden within macros.
What I don't like much is the use of macros, which doesn't make it very easy to have a look at how the generated code actually looks like (well unless you have editor plugins that expand them for you), but I'm not sure it's a big issue. Alternatively we could perhaps use things like #pragma makedep instead, but although it could generate things in clear text in an annex file, it would be more misleading to the uninformed reader.