There is plenty of barely functional cruft in the X codebase.
This is very true, but if I had to steelman X11's colossal codebase that has tons of "barely functional cruft:" the X Window System emerged in the 1980s and grew organically based on the needs of the various Unices of the time. It very much embodies a "better to have and not need than to need and not have" approach. Architecturally speaking: Wayland's limited specification, coupled with outsourcing miscellaneous functionality to the compositor
without applying a rigorous compositor specification,
is bad design. Not necessarily bad code, but the project scope naturally lends itself to ecosystem fragmentation. Furthermore, there are critical functionality gaps that Wayland+compositors can't adequately address
because of the way the protocol+compositor ecosystem is architected: primary monitor detection, global hotkeys, VNC, multi-display setups, these are non-trivial use cases that Wayland+compositors cannot adequately address. Freedesktop is impotent and milquetoast against enforcing XDG standards, and even if they had the power, some projects could just flout them altogether (re: GNOME human interface guidelines). What the hell can Freedesktop even do? Revoke certification? Enforce penalties? They're not like the Unix standard/trademark body, let alone the IEEE people who made POSIX.
Wayland is by no means any worse
I'm gonna try to fight against my biases regarding Wayland and approach the subject sympathetically: all the
software that's within the broader Wayland ecosystem is 100% FOSS, and that software can be legitimately good, hideously poor, or somewhere in between. This is true for all software projects, and there are good things within the Wayland ecosystem
if you have a need for it. I personally don't give a shit about HDR on anything other than my smart TV, I use dual 1080p IPS monitors from that I bought used off an enterprise hardware reseller. For
me, Wayland has nothing to offer that X11 can't satisfy. For people with singular HDR monitors and with an adequately supported GPU (re: AMD, Intel), Wayland is perfectly serviceable. Hell, those people would be able to utilise Hyprland's genuinely interesting featuresets that are only possible by thumbing their nose at "poor" compositor implementations (re: Mutter, KWin, Sway or basically anything else that relies on wlroots).
Wayland's being pushed as the successor to X, and yet the broader Wayland ecosystem itself is a complete and total clusterfuck precisely because the protocol's specification is too narrow in scope, the compositor has no hard specification to abide by, and too much discretion is given between compositor developers and application developers to implement changes. This leads to a significantly worse downstream user experience precisely because the ecosystem can't fucking agree on what it is that they wanna do. I wouldn't have such acrimony and contempt for Wayland, such that it is, if the ecosystem around it was willing to grapple with these shortcomings and address them pragmatically. It's not like the institutional power isn't there to make it happen, since basically everyone across every major FOSS body is either directly on Red Hat's payroll or 2-3 steps removed from people on the same team who are on their payroll. The most elegant solution I can conceive of goes something like this (in sequence):
a) Create a Wayland 2.0 specification that more clearly defines what the protocol is responsible for, what it's not responsible for, and notably: makes concessions for critical shortcomings within the protocol that negatively impacts both home users
and the broader enterprise ecosystem that Wayland best fits.
b) Within that Wayland 2.0 specification, introduce a rigorous standard for the compositor that more clearly defines what their obligations are and how to achieve it. i.e. clearly define a standardised means to set the primary monitor, clearly define a standardised means to allow for global hotkeys, standardised means of handling dual-monitor and high refresh displays, blah blah blah.
c) Proactively work with downstream application developers to ensure that they're all on the same page and that they uphold the standards and specifications set by this hypothetical Wayland 2.0
This is literally what happened to the X Window System. It never became a sprawling behemoth overnight; decades of updating standards and specifications to meet broader market demands happened. Wayland wanted to avoid this, but it's clear as day that you can't enforce mass adoption
without some modicum of rigorous standards and specifications the way that X had. This doesn't mean that Wayland would become a sprawling behemoth like X, not in the slightest. There is real value in a Wayland that learns from X's mistakes, keeps what worked well, discards all the "barely functional cruft," and upholds a similar standard that X had in its halcyon days.
Of course, I'm not so foolish as to think that this would ever happen. Not in the slightest. My inner optimist tells me that it won't happen because of institutional inertia plus losing face by admitting you were wrong on some measure. My inner pessimist tells me that it won't ever fucking happen because it actively benefits Wayland, the compositor teams, and the application developers to keep playing hot potato with accountability because they can do whatever they want with the downstream user suffering the consequences. That's why I have more hope in XLibre proving itself than Wayland's longstanding architectural, structural, and systemic problems being meaningfully resolved.
