Edit: I know that could kind of sound incendiary, but let's consider the facts. We're talking about a project that has been competing with a dead competitor for 15 years and is still struggling to get mainstream acceptance. There's something seriously dysfunctional going on.
Basically, the GNOME devs refuse to provide default window decorations (title bars, etc), forcing all Wayland app devs to draw their own title bars and "X" buttons for their windows. This is a bit silly since some desktop envs do provide default decorations, and 99% of the time you probably want your app to have native-looking title bars.
So now we have 1) ugly window decorations on some apps because that's "according to the Wayland spec", and 2) windows with no decorations at all, but only when running on GNOME. End result is ugly inconsistency that makes it very hard to compete with the likes of macOS and Windows on a visual level. And it's all due to a mixture of human stubbornness and arguably an architectural blunder on Wayland's part (but maybe mostly the former, to further your point...)
That manifests in a bunch of different ways. Lots of desktop software is still using the likes of Gtk 2 and obviously won't get Wayland support without being ported first. Desktop Environments like XFCE and Cinnamon are, again, basically hobby projects and re-architecting them for Wayland is a big ask for non-professional maintainers. And then you have stuff like Zoom and other Electron apps that take their time adopting Wayland simply because Linux was always an afterthought to them anyway.
I'm personally hoping that, come ~2025, Arcan v1.0 is released, the WM crowd largely switches to Arcan-based systems, and Wayland becomes the new JACK (with X being the new ALSA, I guess?).
1) A lot of architectural decisions that made sense in 2008 are less optimal today.
Everything language-wise was C/C++ while today lots of different languages want to interface to your display system. The input system was completely hamstrung--things like gestures and multi-touch and things like that just weren't in anybody's brain yet. (Wayland started just after the first iPhone was introduced). And RT_PREEMPT still isn't a thing for Linux while both Windows and macOS underwent major surgery to allow real-time paths for things like audio and interaction.
2) Desktop composition semantics are not exactly easy to define.
Windows has certain definitions, but even it falls back to pure CPU software rendering in a lot of cases.
3) Weak support from graphics card companies
Windows relies on a LOT of driver hacks so everything goes through the compositor on really fast paths. That's a lot of work that nobody really has the bandwidth to do on Linux.
Although the egl requirement has proven troublesome the times I've dipped my toes in, previously: if I have an NVIDIA or AMD GPU in my machine, I do expect to not get told it's unsupported.
https://www.nvidia.com/download/driverResults.aspx/181159/en...
Do not forget the era where compositors were choosing not to support an open standard of the EGL_KHR_stream extension. Instead they preferred a proprietary solution using Mesa's GBM API.
[0]: https://github.com/swaywm/sway/issues/490#issuecomment-47174...
Having it work surely is better than those drawbacks. Things can be improved and iterated on over time.
Wayland adoption was damaged by this.
>and everyone in the Wayland space had been using the mesa library
They chose to make themselves compatible with a single graphics driver. GBM ended up having to be rearchitected so that Nvidia could create a backend for end.