Quite the contrary. I used to work on a proprietary remote display protocol and the remote X11 protocol is seen as an anti-pattern in that space. X11 requires

Quite the contrary. I used to work on a proprietary remote display protocol and the remote X11 protocol is seen as an anti-pattern in that space. X11 requires draw operations to be applied in-order, so every dropped packet means stalling the client draw pipeline. This is one major reason why other remote protocols use varied strategies that look very different. Wayland, in many ways, accepts that reality and moves the network-portability away from the core protocol. Besides, hardly anyone does draw operations on X11 without the Xshm extension now days, so in practice, many apps are not that network portable. The toolkits go through great effort to make it sort of work. Kinda. If you don't look too closely. That said, you could create a system that supports transparency similar to the old design, but I'm not sure any active contributors are interested in doing so. One major reason for that is that most applications on Linux take advantage of communication buses while also completely disregarding the idea of supporting multiple sessions by the same user at the same time. So to have an application work over the terminal, get a session (d-bus, seat, etc), and then collide with other apps in a second session by the user doesn't make a lot of sense if at the end of the day the user loses state, or worse, gets corrupted files.