I'm aware that extensions exist now, like present, which make it possible to send buffers, similar to how Wayland operates, so you don't have to do things the primitive way.
However, to claim to speak the X protocol, you still need to support the older functionality, that's what I mean by a tremendous amount of functionality to support. The moment you get rid of that old functionality, you've essentially created a new protocol, which is what Wayland is.
How is that point nonsense? I don't want to see X go, but I don't think it's reasonable to prevent progress.
Wayland doesn't break anything, it's a completely new protocol. Claiming Wayland breaks your use case is like saying systemd broke old init scripts. It did because it's a different system.
Wayland isn't trying to be Xorg 2. It's a protocol. At its core it's only a compositor protocol. Everything built on top is up to the implementation developers.
and that's exactly creating the problem: Window management for example is left as an excercise to the reader. thus (my point above) the WSLg interop for graphcial applications _sucks_ compared to where X Servers already were. and if MS doesn't implement what's needed, it won't come. no way to fix it in the Linux or on the Windows side. the MS Wayland thingie in between tightly controls what is possible.
Wayland is an evolution of the previous design. X11's architecture had clients sending drawing commands to the X server, a method that became limited and required extensions over time. Wayland's approach is: applications perform their own rendering into their own separate buffers, then tell the compositor when they are ready. The compositor takes those buffers to produce the final image.
Because those buffers are separate, enhanced security is a direct side effect. Wayland is the result of decades of experience and represents the current way of doing things.