Well sure, this is the kind of output you would expect to see and most often what is being done with similar tools, but I think it's not great for various reasons and I wanted to avoid these in particular. Here's a couple of things I remember I wanted to avoid:
* Moving class structure declarations entirely in the IDL breaks many tools integration. For instance LSP or others would point you to the generated file whenever you want to find the definition of a class member, not to the IDL itself where it would need to be edited. It would also require WIDL to be able to parse many more headers for any type to be usable in class members. With my approach I kept only the strict minimum in the IDL, which wouldn't need to be changed so often and I think it is an important feature to not make development more painful.
* Using IDL-like syntax to declare classes like this would require to add WIDL-specific parsing support for it (ie: more code, more maintenance). OTOH reusing the struct parsing like I did just works already. Similarly, listing interfaces like here works for the most basic usage but as soon as you want to support things like inner / outer interfaces you will need to add WIDL-specific attributes as well and using naming conventions instead, which we already use pretty much everywhere anyway, actually seems more natural to me.
* Using forward declarations and separate `.h`/`.c` also adds more indirection, and increases the chances to get unused functions go unnoticed, or link errors instead of compilation errors. It also adds more compilation units to build.