If Wayland is the future, the future is grim. People often complain that Wayland is taking a long time to catch up to X11, but that actually stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window man…
This is a fair criticism. It is true that we see each of the compositors rolling its own extensions to the protocol. But I believe wayland is trying to standardize a lot of the protocols which should cover common use cases.
> each new compositor implementation reinvents the wheel many times
This is not true. There are libraries like wlroots[0] which you can build on top of. You don't have to redo the work that is already done in other compositors.
> application that needs to grab the entire screen will need separate code for each compositor it supports screenshots
There is the PipeWire[1] effort to support screenshot and screen capture on wayland in a unified way.
> Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
Also not true. On a properly implemented compositor, video games frames shouldn't have longer latency to screen than on Xorg. X server has to do composition too, whether you run a compositor or not.
[0]: https://github.com/swaywm/wlroots [1]: https://en.wikipedia.org/wiki/PipeWire