Comment Wayland is a non-solution looking for a problem (Score 2) 210
I've played 3D games just fine under X, run VR with the Valve Index while X was up, can generally work fine with international text and image pasting, etc, etc. I deeply value the ability to swap out to different window managers, although fvwm has worked well for me for a good while (after having gone through about 10 others). I value this because anyone designing how the window environment should work is very, very likely to break something fundamental, and often utterly fail to understand why it's a problem. I use remote X windows over TCP ** ALL THE TIME ** even just between computers at home. I even use features like Emacs's ability to open windows on multiple X servers at once.
X does have its flaws, but the only one that's every blocked me is the fact that the library and protocol make it seemingly impossible to cleanly forward non-faked X events to a specific X window including the pointer coördinates without involving the entire bloody X display structure - meaning that managing a bunch of interactive textures texturing 3D objects requires screwing around with a hidden X display and popping a specific window to the top of the stack to map coörds display-wide, which is mind-bogglingly inelegant. Hopefully I just missed something...
(For this paragraph, my information is from a few years back, so let me know if Wayland has solved any of these below...) However, Wayland's pretty useless for many things given its:
* general lack of any way to run X programs (individuals windows) on the same host,
* a way emulate at least an X server for X programs to use (something I've written myself before, although I modified my X server to use an OpenGL texture format for the X server display buffer so I could map a display onto any object)
* a way to run a program on one host that displays its windows to a different host - this ability is CRUCIAL in many applications
* (rare) a way to run a program that can display windows on several hosts simultaneously (like I said, even Emacs supports this... though the emacs proc will die if any of the X servers it's connected to do, which is a bit fragile)
X's core win is that it is fundamentally a network protocol, while gamers want the supposedly opposed core win of optimized local hardware use. But this don't have to conflict - you can see how OpenGL was aiding the joint effort with display lists, which allows your vector info to be pushed to a local OR remote display (using GLX) and then call it on either by the list's identifier. Still, this doesn't scale well on slow networks with scenes with lots of dynamic objects.
What would be ideal is to have full local hardware support, and for the remote display to be able to use *either* a high-level protocol (as was GLX for OpenGL) **or** some per-window VNC-style fallback, depending on the bandwidth. And the graphics-level protocol can be faster than one thinks - remote X in many applications was slow because Xlib was based on serialized events, where the xc library parallelized event handling, making them shockingly faster.
There is a deeper problem though, that both Wayland and X fail at: I want to be able to keep up sets of 2D (for example) windows for *all* of the stuff I work on, spread across all my hosts at home and whatever I'm using for work, in one big, shared environment - and I want that set up to be be resilient in the face of any host crashing, so that I can connect to that environment from any host, or reconnect if the one in front of me died, and still have most of it reappear when I log back in. Until we have something that gives that level of ease of use, we're still basically just using toys, regardless of how good the hardware acceleration is.