tbh the biggest problem facing wayland isn't the features WAYLAND supports but the proliferation of compositors supporting different extensions. something that works in sway might not work in gnome and vice versa, which is really unfortunate. and then users will scream online that "wayland doesn't support $feature" when in reality it's that "gnome doesn't support $feature (but sway might)" or "sway doesn't support $feature (but gnome might)" or most pathological of all "gnome and sway both support $feature but it needs to be used in slightly different ways and i'm following instructions for gnome when i'm actually using sway or vice versa".

there is such a disconnect between the perspectives of those of us actually developing the linux graphics stack and users trying to use the polished system we release. and yeah, if you do things The GNOME Way or the KDE Plasma Way things are usually mostly ok. when your point of reference is some funny boutique setup (I once ran MATE with i3-gaps as window manager, I get it), yeah things don't look so nice.

i don't know where we go from here. my ux profs have thoroughly convinced me not to blame users since it's our own damn fault for publishing 4 different independent compositors with different feature sets and different configuration mechanisms and all calling them "Wayland". but as long as DE tribalism plays a role in protocol negotiation it's uphill.

wayland started with a simple graphics idea -- every frame perfect. it's accomplished that. graphics under wayland are years ahead of anything x11 is architecturally capable of.

unfortunately it turns out graphics is easier than politics.

i'm not going to tell you what to do. but there are excellent reasons why graphics developers are pushing wayland. and there are understandable reasons why users push back.

i can't solve ecosystem-wide conflict. hence the zen of display servers. use x11. use wayland. use pineapples. i don't care what you do, just don't bother me about it.

i should get back to reading my book now.