Related: There is an in-development Wayland compositor for the Window Maker look and feel called wlmaker¹. It is already quite usable, but is very barebones right now.
X11's architecture, on the other hand, is arguably better than Wayland's. Server-side rendering is a great way to
It also has lots of flaws. "Mechanism, not policy" has to go, because you are trying to make a desktop environment, not draw arbitrary rectangles to the screen. It is already a given that there is one special client called the window manager; it would serve the architecture well to know that's the window manager instead of treating every client as if it could potentially be a window manager. But Wayland goes even further in this direction, eschewing things like icons, title bars and resize borders, which are basic expectations of a desktop environment. While X11's way of doing these things is esoteric, at least it has one. (If it were up to me, standardized window properties would be promoted to requests, so you'd just call xcb_set_window_title instead of fussing with atoms and window properties).
Another anecdote is HDR: Wayland seems to still have not standardized how it should work; meanwhile on X11, there is already protocol support for multiple pixel formats (1-bit, 4-bit, 8-bit, 16-bit, 24-bit displays) and you could just add 48-bit color to that list. That would be one of the things Wayland stripped out while striving for simplicity (since everyone had 24-bit colour at the time) that turned out to actually be important.
---
At some time before the heat death of the universe, I will get around to trying to fork Xorg and remove all the cruft and see where that goes. (Server-side rendering is not cruft. User-mode SVGA drivers are.)
I did minimal work on this already - as in, I downloaded Xorg's source code and had a look through. The whole configuration system has to go. The XFree86 driver code and driver abstraction has to go, and the DRM driver hard-wired in place. Using dlsym to locate compiled-in modules makes tracking dependencies impossible.
I suspect this has something to do with the state of Xorg: Nobody knows what it should and shouldn't do, and the module API for Xorg is the entirety of Xorg, so changing anything is liable to break someone's external module that wasn't on the "it should do this" list.
It wouldn't be the first time the X server was forked with the intention of cleaning it up: Xorg is a fork of XFree86, which was a fork of X386, which was based on something I don't remember.
There are some advantages and disadvantages of the approach.
However, there's just stuff that X assumes that isn't true anymore. A good example is how it handles input. How many cursors does a screen have? One machine? okay, One input device?
I'll have to see the talk later. If a new input model is needed, why can't it be an incremental upgrade? I know that UI frameworks still have the traditional mouse down/up/move events, so they've been able to make it an incremental upgrade in that layer. If it's so incompatible that it can't coexist with the old model in the same connection, we make it an option for the client to request. If we're very very sure it's the future, we make it X11R8 or even X12 (the difference between X10 and X11 was smaller than this), we allow the server to support X11 and X12 clients and deprecate X11, and remove it after a very long time (if ever). All of this is still less invasive than Wayland.
It did have some of the worst code in open source. We didn't need to abandon the protocol, ABI & backwards compatibility (fuck Wayland sideways a broom) but a rewrite was sorely needed
x11 doesn't do much of anything to begin with, these days. It will still exist for the people that want to use it, but distros are right to not default to it anymore.
Why can't we have a wayland server that can run different window managers like X did? That way, we only need one wayland compositor, and everyone can just write their own window managers.
This looks doable. Create a Wayland compositor that does not do visible window management itself, but exposes an API to help relatively easily port and run an ICCCM-compliant WM.
This looks so obvious that it ought to have been tried.
It's the first, and hopefully the only, time I will say I'm glad I see something on Wayland. I had some nasty visual issues once with WindowMaker, I feel like such a fundamental move is needed.
¹ https://github.com/phkaeser/wlmaker