I think these worries are unfounded atm, because compatibility is good for most applications, even though there are some tools specific to a compositor (e.g. wa

I think these worries are unfounded atm, because compatibility is good for most applications, even though there are some tools specific to a compositor (e.g. waypipe for wlroots based compositors). For the case of minimal window managers, there is wlroots, which is designed to be used to write a compositor. The first line of the wlroots repo[1] states: »Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.« And there are at least three[2] actively maintained compositors based on wlroots. Sway being the most popular, the one for which wlroots was initially developed for. I believe that there won't be too many incompatibilities, because there are 3 (4, including weston) wayland compositors developed (Gnome's, KDE's & wlroots based), all three of them having their own use cases. Using protocol extensions only useable on one compositor would limit the app to a subset of Linux Desktops (and mobile), so if possible, most apps won't use them. PS: I just remembered one case of fragmentation: Activity Watch, a tool to keep track which apps are used how long and to track idle times, won't be able to support Gnome (mutter), because Gnome dev's won't implement the necessary freedesktop protocol extension. Sway (and KDE?) does, so it works on them. One solution would be to write a Gnome Shell extension, but yeah, it's not as easy as on X.org (reason being privacy, in this case). [1] https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots [2] https://arewewaylandyet.com/ https://arewewaylandyet.com/