I've largely come to the conclusion that 1) X got as bad as it did not for technical reasons but because of designers stuck in the past (see below), 2) Wayland inherited many of the same architecture astronaut attitudes.

You see this if you look at e.g. XRender. XRender was a big improvement for X, by providing a set of rendering primitives. Yet at the same time they repeated mistake after mistake from the core protocol. E.g. the flexibility in visuals that mattered when we did have monochrome, 8-bit palettes, 15-bit direct color, 16-bit direct color and 24-bit truecolor graphics output in the same computer lab no longer matters when you can assume that every server can provide RGB24 and RGBA32 visuals, not least because XRender demands this so if a server wants to support XRender, it must support RGB24 and RGBA32 whether or not that's a natural fit for the backend or not.

Yet it still makes you iterate through a list of every weird format known to man (and some that feel like they must be alien) even when you want to look up one of the 5 standard formats Xrender dictates that every server must support. Xrender could have just made the relevant request return 5 ints.

It's not hard to deal with the current solution, but it's pointless and it makes the server unnecessarily complicated to still support all of those extra visuals that almost nobody will be using, and nobody needs to use.

If that was all, it wouldn't be so bad, but this is typical for XRender, and this is why X became unmanageable: They both left the core protocol intact, but each extension they added was just as bloated as the core was.

Nothing would stop you from fixing this by bumping a version number and start deprecating requests and introducing replacements. But that only works if you can get buy-in into changes that actually simplifies things, and the XRender extension is a good indication that this was the real problem for X: You'd get buy-in for changes, but changes that only ever added complexity.

This was particularly idiotic because Xorg came to pretty much control this space: Almost everyone used the same X server and almost everyone used the same Xlib. They could have bumped the protocol version and started deprecating old functionality whenever they wanted while optionally papering it over in the client lib to give people time to update their clients.

So Wayland became a way of escaping that and starting over. And it could have been great if they weren't so afraid of repeating the same complexity mistakes that they repeated the same complexity mistake by proxy by forcing even basic functionality into extensions where there was no ability to reign it in. The Wayland design reliance on extensions made an explosion in complexity virtually guaranteed.

I wish they'd have forked Xorg instead, and had the guts to gut it and clean it up: Bump the major version to 12. Set out an aggressive deprecation schedule and ensure a sufficient set of apps would keep working with various calls and visuals yanked out. Optionally add a shim to xlib/xcb to temporarily handle some of the deprecated functionality client side (e.g. most old rendering calls and bitmap font handling could easily be transitioned this way). Then you'd have a base to iterate from where you could iterate step by step from a working starting point. Then maybe we'd all be on something new and working instead of having this ongoing schism that won't be resolved anytime soon.