> massive fragmentation issues across the graphical part of the Linux ecosystem This is a fair criticism. It is true that we see each of the compositors rollin

> massive fragmentation issues across the graphical part of the Linux ecosystem 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 https://github.com/swaywm/wlroots [1]: https://en.wikipedia.org/wiki/PipeWire https://en.wikipedia.org/wiki/PipeWire