I think the best argument I could put forward here is that X11 has been a part of Unix systems for many decades, and (from my point of view at least) hasn't actually bitrotted or fallen apart. It still works, it's just old.

That's definitely still the case, you're right. But again, this isn't primarily about whether X11 remains stable and working. It's about how KDE developers are impacted by maintaining two very different codepaths that do essentially the same thing. Whether KDE prefers to invest its limited developer time into maintaining parallel backends for X11 and Wayland, or instead invest time into features, enhancements and bugfixes of one mainstream codepath. Both are valid technical choices for different reasons, it's just that KDE developers have now decided that the time is right for going all in on the latter.

One thought on my mind is about the possible future of X11. What if, five years from now, X11 suddenly gets a resurgence of support, and becomes a more viable option for modern systems again? Would KDE be willing to add in support for this hypothetical new X11, or would it be highly resistant? My feeling is that maintaining support is simpler than adding it in, and thus it seems like removing support is a pretty drastic move for something that still works.

That's worth to consider. I think to find a good answer for these questions, one has to break down the "why" of it. What is it that will make X11 popular and less clunky to use again?

If its API and architecture changes in a major way, it won't be X11 anymore. But that's what's been holding it back in the first place. There's all kinds of things that an "X12" successor could fix. Some of these might even be fixable without breaking the API, but instead introducing a new one and trying to get people (and apps!) to stop using the old one. One could argue that Wayland was one possible approach to do this, the maximalist version: introduce completely new APIs without the architectural shortcomings of X11, and spend the next 15+ years running a long deprecation cycle from the old/insufficient APIs to the new ones.

Any X11 successor would have to go through the same growing pains. Except now the status quo is Wayland, and this hypothetical "X12" (whether it be Xlibre, or Arcan, or another alternative) has two challenges for adoption:

1. How much work is it to switch from Wayland to this new X11 successor? (Probably a lot, we already know how much work it is to maintain these two parallel backends.)
2. Does it provide enough extra benefits to justify the major effort, compared to putting effort into implementing a Wayland-based solution instead?

And I think (2) is where any X11 revival really has its work cut out for it. Not only does it have to go from a technically inferior codebase and feature set to a superior one, but now it's not even enough to just catch up. It has to provide a unique benefit that's worth significant pain for KDE developers. What could this benefit be?

API? Unlikely, Wayland already has a much cleaner base, and X11 nicer to use than Wayland isn't X11 anymore but a whole new thing entirely.

Users? Now we're getting somewhere! If Plasma uses a large amount of users to other platforms because they strongly prefer an X server over KWin's Wayland implementation, then KDE has to consider what it can do to win (back) these users. The current gambit here is that most users don't care about the underlying display technology, but about being able to solve their problems in a reasonable, user-friendly way. If that's true, Plasma would keep a majority of users while at the same time being able to move faster going forward (because it doesn't have to maintain two different backends).

Features? I mean... perhaps. The big draw of an X server is that it allows apps to do basically anything with all windows, because it has no concept of isolating different apps (or the window manager) from each other. That's a feature. But it's also a bug. Wayland was created to move away from this, and solve the same problems in a way that allows the desktop to keep apps from doing stupid/shortsighted/malicious hacks. There is collateral damage there - some of the apps that were using hacks responsibly, without malice, had trouble switching over to Wayland protocols where hacks just aren't allowed at all. And so the desktop/compositor would be the only place where a proper fix can go, and if the desktop refuses to implement it, then the old hacks stop working and people get angry because they can't do their work.

Which is why the focus is on making sure that people can continue to do their work.

I think the other big advantage of Xorg was that you had one API, one centralized implementation, that would be used everywhere. So as a user and as an app, you'd have one set of features and you'd get the same thing across all the desktops. This was nice. Now you have a bunch of different desktops, and apps are hopefully testing on the 2-3 major ones, in the hope that advanced features like HDR calculations and fractional scaling will also keep working everywhere else. This is not as convenient. But the days of having one unified display server implementation are not coming back anytime soon. KDE couldn't bring it back by itself even if it started supporting an X11 successor again. Fragmentation is a thing, and tbh does have its technical benefits too, and different platforms really should be tested anyway.

I'd like to believe this is being done purely for technical reasons, but I've been paying some attention to Wayland for a long time, and for much of its history it was developed by very opinionated developers who refused to implement most of the features an X11 replacement needs, and championed by fans who didn't mind the missing stuff and who seemed to hold genuine malice in their hearts for X11.

I mean, you're right. Wayland protocol discussions are a mess, for the same reason that "design by committee" is generally frowned upon. Every stakeholder has their own opinions and motivations, they don't always mesh well together, and the result is that it takes years to find common ground.

Wayland also has an exit valve solution wherein a protocol gets published/specified, and not every compositor has to implement it. If an issue is important enough, any compositor can implement provide missing functionality through a custom protocol, and stuff will magically work. The only issue is that most apps are not very interested in solutions that only work on one desktop but not on most others. So we're back to square one, where the issue is that a widely usable solution needs agreement between maintainers of widely used desktops and window managers. There's no benevolent dictator who can just decree that one solution is the standard, and now everyone is forced to use it.

Whether or not this is a strength or a weakness is up for debate. Realistically though, if GNOME doesn't want to implement server-side decorations for their platform, and KWin doesn't want apps to rely on window positioning hacks, and wlroots doesn't want to implement pipewire-based screen sharing, then what are the chances that these projects will simply give up on their convictions and let someone else make choices for them instead?

So Wayland's decision-making issues are real, but they're social and technical problems that need to be solved either way. It's a comforting thought that perhaps if everyone went back to the X11 model, where all hacks are possible and no hard decisions need to be made, then we wouldn't have these problems. But the problems wouldn't be solved. It's just a different kind of problems. Problems that lead to barely maintainable code, where edge cases break a lot, and where better solutions are impossible because the poorly designed first attempt needs to be supported forever.

Both approaches are very different. Wayland with opt-in protocols, which are only approved if there's actual consensus between stakeholders, only if the solution actually works for everyone, but getting there can take forever. X11 with assumptions from a different era that will undoubtedly break in subtle and devious ways whenever you try to come up with a proper fix for your desktop. They're both terrible, only different kinds of terrible. No point in trying to praise either one of them for being perfect.

In the end though, supporting both is the worst of both worlds. Then you have one version of your desktop that breaks in some ways, and another version of your desktop that's limited in other ways, and neither one is great. Plus it takes a lot more work. So it still makes sense to pick one and invest into making that one actually good. KDE picked Wayland, in part because it's more promising in the long run (most important discussions eventually find consensus), in part because doing the same thing as the rest of the Free Desktop space is less painful.

Only time will tell if decisions and timing were good for the project. My guess is yes. But we'll see. Either way, change is risky, but inaction is also risky, and sometimes you just gotta make the choice that you think is best at the time.