I'm not sure why host events would have to be forwarded at all with this architecture.
I am thinking that the process that owns the wl_surface (the desktop process in the design described above) is the one that receives all input and must handle all output for it and all this involves some per-process state. So, either the desktop process handles all that state, making the processes owning the HWND much leaner, or we somehow forward that state to the HWND process to handle (BTW, this seems quite painful, would not recommend).
Of course, there is the ideal scenario in which Wayland gains a protocol for (securely) implementing cross-process subsurfaces and presentation. From what I can tell, such a feature wouldn't go against basic Wayland philosophy (as long as it's secure, so no arbitrary access to foreign surfaces), so I don't expect it to be blocked on such grounds, but I expect there will be difficult technical/semantic considerations to resolve.
For DirectComposition would the idea be that the host system handles the composition completely (through host child surfaces), or do you expect that Wine would also grow a full-fledged compositor (performing full input handling at the "root" level, compositing to a final surface that is the handed to the host etc)?
With that said, it may be possible to find some early steps in that direction, that would also fit your needs for winewayland. ...
Ack. This sounds like a reasonable way to proceed, I will start exploring this avenue. There are several unknowns at this point for me (esp. in terms of how we would like this to evolve going forward), so I expect this will take a few iterations until we reach a solution that we like, but I am hopeful :)