In response to Wayland Breaks Your Bad Software
I say that the technical merits are irrelevant because I don’t believe that they’re a major factor any more in most people moving or not moving to Wayland.
With only a slight amount of generalization, none of these people will be moved by Wayland’s technical merits. The energetic people who could be persuaded by technical merits to go through switching desktop environments or in some cases replacing hardware (or accepting limited features) have mostly moved to Wayland already. The people who remain on X are there either because they don’t want to rebuild their desktop environment, they don’t want to do without features and performance they currently have, or their Linux distribution doesn’t think their desktop should switch to Wayland yet.
What has kept me away from Wayland is the tendency to be dependent on the compositor for so much.
I use my preferred X11 window manager for largely aesthetic reasons, but by and large, I can swap it out and the rest of the software doesn’t give a damn. At most, you might have to tweak a RC file to fix missing custom assumptions (i. e. disabling decorations on full-screenified Proton games)
It seems like on Wayland, there’s a lot more of a “if you aren’t using GNOME or KDE, the odds something meaningful breaks are much higher.” Aside from the perceived bulk of these environments, they’re highly opinionated-- I suspect it would be a major production number to hammer them into a shape that looked like FVWM or WindowMaker, even if you only wanted to match a single theme’s aesthetics (as opposed to, say, FVWM’s dynamic configurability).
If you find a Wayland compositor that’s based on wl-roots, you basically get that ability for swapping out the window manager.
The wl-roots project aims to be a common library that any project can pull in without having to implement the required Wayland protocols themselves.
But even that’s a relatively high bar. Wl-roots is self-described as “60000 lines of code you don’t have to write yourself”, and any arbitrary compositor may not use it or may not be up-to-date with it. In X11, you don’t need 60,000 lines of code to be functional. Hell, the example Window Manager that was printed as a couple of chapters in the old X11R5 reference books works well enough especially considering its size.
I feel like I missed the historic genesis of this particular quagmire. Knowing that a composer was essential, you’d expect developers would want to make very robust core functionality-- a super-rich libweston or something like wl-roots, so that “real” compositors would just be paper-thin extensions that answered the opinionated parts. Did early Wayland design get bogged down on embedded-style use cases where such features were seen as too expensive (compare: no built-in printf in C), or was it a deliberate territory grab by early compositor developers, trying to turn it into a place they could to gain competitive advantage?