@dalias @mhoye ok, but you can do that with Xwayland too. As a technical matter at the point you define a process to run each container with its own Xnest or whatever, don't you need to solve some of the same technical problems with input handling and global key bindings at the window manager level that you do in the Wayland case? What technical purpose would this serve except to keep the pixels X flavored, how do you provide zero copy direct GPU rendering to apps in this case?
I'm not a desktop app or graphics developer, I just make forms in CGIs for useful little crud apps, but why are we so quick to dismiss the experience and judgement of the seasoned professionals and volunteers who are actually ass-deep in the graphics stack to have good ideas for what is technically a good design. A lot more people who are working no toolkits, window managers, desktop environments, distros etc. seem to think Wayland is a good enough idea to implement it, there is no central authority who can force all these volunteer projects to adopt a change like this, so what do they see that the critics don't?
IIUC Wayland just defines a very simple mechanism (not policy) for window managers to use the Linux kernel APIs to hand out GPU buffers to apps, and feed them input events, everything else are dbus APIs and conventions from the desktop projects. It has all the same problems with coordination between multiple desktop projects, toolkits and app ecosystems that X11 had which was worked out 30 years ago by the Unix workstation vendors who were trying to build a business on top of it, there aren't as many resources for desktop infrastructure today (my opinion, maybe I'm wrong) because no one is losing a billion dollars if they don't ship next week. There is still _some_ interest, which is why RHEL10 uses Wayland and Redhat pays for FTEs to work on the details like accessibility, but I think this has been primarily volunteer driven over the last 10y.