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.)
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.
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.)