[wongarsu]

One clear sign that classifying them as misfeatures is not a consensus view is that every major OS has those features.

The security model changed drastically, and with them how those features are presented. For example Windows, being developed to the threat model of the early 90s with some stuff tacked on in the aughts, has powerful APIs for reading window content in a structured way, for getting screenshots and for injecting arbitrary inputs, and only has some tacked-on protections that protect higher-privileged processes from lower-privileged ones (e.g. task manager runs with admin privileges, and you can't inject inputs into it or read mouse events of a cursor over it unless you run with the same or higher privileges). Android was built to the threat model of the aughts with additions in the 2010s and 2020s and has great APIs for reading window contents in a structured way, getting screen content, adding overlays and injecting inputs, but they are gated behind strong capability-based permission systems, review in the most common app distribution system (play store) and require the human to jump through various hoops to confirm this is really their intent. iOS ... restricts a lot of that to Apple, because they don't trust app developers.

X.Org does all of that with a permission model similar to that of Windows NT4, without the added restrictions Microsoft added later. That is the misfeature. Wayland looked at that, looked at the ability to make something better in the somewhat disjointed linux/*nix ecosystem and decided to just not have those features rather than have a good security/permission model

[rcxdude]

This is more or less the headache, I think. A complete lack of urgency around the idea that wayland did need to have _standard_ interfaces for doing pretty much all the things that people were doing with X11. Yes, it's more difficult to design them in a secure manner, but there seems to be just a strong attitude of 'well, you don't actually want to X because...' which has proven to be a massive barrier to adoption (at least, I think it puts people off and slows progess much more than 'we understand it's important but haven't had the time to sort it out, sorry'). This has been especially bad in matters of taste where some projects or members thereof don't like some concept or another which developers and users have gotten very used to (and can in fact be done securely and with respect for the user), so it just gets stonewalled and disrupted at every turn.

As a result, generally the answer to 'how do I do X in wayland' is 'you don't. here's how you do it in KDE, here's the extension you need to install in GNOME to be able to do it, and you're rolling the dice on any other DE'. And that's as a developer, if you're a user there's a good chance the developer has gone 'fuck it, I'm sticking with X11'.

(This fragmentation is even worse when it comes to configuration. e.g. for something like graphics tablets, where there is a relatively complex configuration of how the features on the hardware map to delivered input events, it's left up the the compositor to handle how that's configured. Which means that there's basically no standard way for you to configure your tablet, and there's no complete option: you are either forced into GNOME or KDE because you need some option one supports and the other doesn't, and if you're on a smaller one, you have basically no chance. X11's architecture meant this tended to be much more standardised, and while each DE had its own UI for configuring an input device, you could in practice always fall back to another tool, even if it was usually an arcance CLI, to get what you want.)

[okanat]

I think the failure wasn't Wayland itself but the failure of building another layer on top of it that unified desktop use case. Wayland could have stayed as the protocol to allocate buffer on the screen and passing events to them.

Wayland was designed by people who worked on embedded / mobile systems (some of the Xorg devs who created Wayland were MeeGo developers). It is fine to forego window management and other complex things on embedded systems and leave it to things that build upon them. For desktop another library like libdesktop-window-managment-features would be alright.

The problem arose when GNOME, with their infinite stubborn wisdom, used the lack of various desktop features in Wayland to further their mission to provide a barely functional desktop. Since they also maintain GTK / Cairo / Glib (which both Firefox and Chromium rely on to display things on Linux) everybody else was forced to obey GNOME's crappy world view.

The other DEs and toolkits are prevented from forking the entire Linux desktop environment unless they also want to foot the cost of porting both browser engines to another desktop toolkit / window management system and many popular GTK apps like Inkscape, Libreoffice and Gimp. They definitely have less funding at the moment.

All in all though, without a hard fork away from GNOME and GTK, Linux desktop systems will only cause unnecessary pain upon themselves and their users. They need to find partners like Valve (which already work with KDE) who will fund the projects and move away from GTK / Freedesktop to found something better.