X sucks in many ways, but that is not super important. What is important is that X WORKS. It does what it needs to do and it does it quite well, eventhough the internal details are quite ugly.
X needs to evolve and add additional protocols to remove a few warts, but it works.
It is important. X is an architecturally flawed part of desktop Linux that harms security, privacy, and performance. It is both over complicated and feature incomplete for what is necessary for the part it plays in a modern graphics + input stack. For aspects like improving security you could technically address this by adding additional extensions and then migrating apps to use them. While you could just keep adding extensions to X and then migrate applications to onto the new secure way to do things. There is value in existing technology that works, but there is also value in simplifying the current architecture based off how modern hardware works and improving security in a world where users run code from untrusted sources. While the Wayland ecosystem is being developed, since X will still work, the lack of resources being invested into X is not going to be a large problem.
It is important that as operating switch out X for Wayland that they try not to break as much as possible which is why the Xwayland backwards compatibility layer is important. The goal is for everything to keep working, but for users to gain extra performance, security, and privacy.
I want to ssh -X into a remote machine, run a command and have its window show up, seamlessly, on my local desktop.
If your solution is "use vnc or rdesktop" then I will come to your house and dillate you with a plumbers showel until you see the errors of your ways.
Since computers are exponentially more powerful and have exponentially more memory retained mode is no longer a benefit for drawing the contents of your applications. Modern applications will render straight to a texture which eventually will get composited into the final image shown on screen. Similarly remote rendering is evolving to just a raw video encoding of the frames being rendered. Simplicity wins in the end.
By default GLX, the OpenGL extension for X, can not be used with X11 forwarding. Indirect GLX is what enabled streaming OpenGL commands, but it was not supported well, is stuck on an old version of OpenGL, and was a security nightmare so it was disabled. Especially with the rise of laptops and mobile, there is not a big interest in continuing to invest in servers telling the client to render things locally on its behalf. There are big energy and complexity savings by just having the client use a hardware video decoder.
The project you are looking for is called waypipe. It runs both on the server and the client. The waypipe server pretends to be a Wayland compositor and it proxies messages and the graphics to the waypipe client which handles passing that to the local Wayland compositor on your machine.
