Ok, let me fix my language. Thanks for the reference definitions, I’ll freely admit that I’m a bit rusty.
I was considering Wayland to be the server, not the protocol. I’ll adjust the spirit of my argument with this correction, and take you through a sample use-case of a system I ran on X about a decade ago.
I was arguing that having many implementations of display clients maintained by many different DEs can lead to a contradictory and confusing management environment. I’ll adjust this argument to also include the fact that the display servers are also being separately maintained.
The system that I ran a decade ago was a research box that about a dozen scientists would remote into via vnc from their laptops. Each scientist had their choice of DE which they could run and manage via the .xinit
file in their home directories. This gave them a lot of choice and freedom over how they set up their personal UI (people can be finicky and prefer specific workflows), while also allowing simultaneous resource usage of the data and analysis drives, and the hundreds of cpu cores for various runs, and the hundreds of gigs of ram.
Such a system in Wayland-world would require each scientist to customize their environment using a DE-specific display-client-side configuration management scheme. Each of these would then have to talk to a different display server, as implemented by their specific DE. Sure, each client-server pair is using the Wayland protocol, but running a dozen display servers in the extreme case of a dozen different DE choices is not resource efficient. In a Wayland-world, I would probably have to enforce a standard server implementation of the Wayland protocol to cut down on all of the different display servers clogging up the memory and cpu usage. Sorry if one scientist wants KDE and another wants gnome and another wants i3 (now sway/wlroots), we have to cut down on diversity and user choice because of the fragmentation of the display environment. Under a single X server, it was easy to allow for user-facing interface diversity because of the standardization of the display server. Under my understanding of Wayland (as updated by your comment), supporting this interface diversity would require server-side diversity and server-side system resource duplication that would hinder the ability to efficiently present diverse options to the end users.
If there is anything that I am still misunderstanding, please continue to correct me and help me get caught up on missing the last several years of reality.