@BrodieOnLinux wayland isn't really what it's cooked up to be, even though it has been decided it's the future of the linux desktop, and it could be eventually, if these issues are solved, because the fundamental architecture isn't flawed. The rest of the toot is elaborating that sentiment. This is a very long post because it also details a case I know well about trying to introduce new protocols to wayland, so if you're reading this, it's recommended you read it to the end.

First, differences in compositors and how they implement things, each compositor could implement a different set of protocols, and even what it implements from the protocols list could have its own quirks, which makes it incompatible with current implementations in other compositors.

Then, the effort required to build a wayland compositor from scratch is huge and wlroots isn't always an option because not everyone wants to be writing that in C, though I understand that's not so much of a problem, since so many xorg window managers are just forks of a previous project.

The biggest one though, accessibility took an enormous hit with the keybindings and the snooping on each other applications could do on x11 gone, so now overlays for specific disabilities are impossible to be done externally, and therefore tailored for each use case, they have to be built in the compositor, if the compositor maintainers even agree it's a necessity in the first place, which is also problematic because it's not always the case that our needs are understood, and as such, that our patches for such needs would be merged upstream, and as everyone knows, forking is costly, so that's not a better option either.

Of course, then we go on to more general issues, such as IMEs for japanese, chinese, etc not working properly anymore, and generally neesh software which a couple people used, or even made, to solve a problem, doesn't work anymore in wayland, and if we want it to work again, we have to go through a very specific, ahem, dance.

Well...first things first, making a protocol which should conform to a lot of unwritten dogmas about how security should be done in wayland, beyond the obvious, so then that means spending time around the wayland protocol trackers to learn what the community generally wants and is written nowhere, to increase the chance of the protocol being merged that is.
Then comes the only mildly annoying part, making the xml files for the protocol by hand, which isn't necesarily the most pleasent thing to do either, but not as bad as the next part.

Of course, the final part, getting the protocol in a pull request or an issue, only to find out that first, you gotta sort through a huge number of comments, and I'm sure you know what I'm talking about because you yourself saw what's in a typical protocol proposal, and then to hopefully find out that either your protocol is silently just not merged, it is but no one wants to implement it, or someone kindly telling you that there are lots of security concerns with your protocol and back to the drawing board you go.

A friend of mine went and did the whole dance, trying to find a solution for at least one problem in the screenreader accessibility case plagueing wayland users, the key event capturing, to then be sent to an assistive technology the user configured, like in, say, any other operating system with accessibility support that I can name.

He went to the gnome accessibility matrix room, and both of us along with some of the gnome people tryed to make a way to do it. It took the form of two meetings, I believe they happened last year or so, in one I was there, in the other it was the other way round.

So, we tryed with a portal first, modifying a bit the global shortcuts one to provide screenreader semantics better, for example to consider capslock a screenreader modifier. Then, that didn't work, so he went back to the drawing board, tryed to make a wayland protocol for this, which was kinda simplistic at first, but then gained in complexity.

He almost implemented it in mutter, except that xkb_common doesn't support capslock as a modifier, which is required for screenreaders, because that, aside from insert which is also not a modifier in the actual sense of the word, is the only other modifier applications and desktop environments don't use, that's why screenreader commands usually begin with that key.

The next step in this, of course, is to follow the chainin of events, and file an issue with xkb_common, which is exactly what he did.

In the above mentioned xkb_common issue, we found out it's actually very complicated, more so than we expected, it's not really closed but we know progress is hard to get done, if at all.

So then, probably odilia, the new linux screenreader which is in like less than alpha stage, will still use evdev for the time being, untill hopefully the new wayland based accessibility stack which is coming out will mature enough to replace at-spi, and will hopefully have the right extension points for us, even though it can be a way harder thing to support for wayland compositor developers, with yet one more thing they have to add every time they make a new compositor.

So yeah, I'll continue to use wayland from time to time, and some days use a plasma session entirely with wayland just because, however, these issues are a real bummer all round, worst of all when it comes to accessibility, which could make the desktop for some people, depending if they use lots of gtk4 applications, entirely impossible to use with any semblance of productivity.