> There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own inc

> There are extensions to Wayland that add missing functionality, but those are compositor-specific. Meaning effectively that each compositor has its own incompatible variant of the Wayland protocol. Well no — this is where I disagree. The extensions are standard and hosted within the repository [1]. A repository may support their own proprietary protocol, after all it’s an XML file, but practically speaking without distributing it through the repository means that you won’t get any clients to actually use it. It is wrong to suggest that there is a huge proliferation of interfaces. It is true that the core Wayland protocols support less functionality than X11. It’s also true that developers implementing windowing managers need to do more work — however, again I point you towards wl_roots, libinput etc. as examples to show that you don’t need to implement anything from scratch unless you want to. I don’t believe this particular design doesn’t have trade-offs, but to pretend that it has no benefits is also incorrect. The fact that there are less core protocols means that you can implement a simpler compositor if you should so wish. There are comments in this thread pointing to the usage of Wayland in different devices as an application of this. [1] https://github.com/wayland-project/wayland-protocols https://github.com/wayland-project/wayland-protocols