Don't worry too much about the duplicated effort of different projects implementing the same standard on their own. It's good to have lots of implementations of a standard. That's what makes it a standard rather than just some code we all depend on.

Things like taking screenshots and setting wallpaper actually do have a standard API. That stuff is just part of xdg desktop portals and not the core Wayland protocols. If, for example, a screenshot app uses the org.freedesktop.portal.Screenshot API then it should work with any compositor (as long as the compositor follows the API standards).

- person using software developed in opposition to monolithic architectures rediscovering the benefits of monolithic architectures

Wayland isn't to blame for duplicate effort. Instead of 4 different efforts doing the same thing, they can collaborate to build a common base. Heck, wlroots is exactly that.

There's a ton of duplicated work in Linux ecosystem. Just think about every new distro coming out doing the same things other distros did. Just think about all those package managers on different distros. They do almost the same thing. Do they need to have codebases that share nothing? No. But they don't care. They rather duplicate effort. They chose this.

I don't quite follow your arguments. X11 got big and bloated, wayland applications need to worry about the different compositors? So we should use one implementation? Implementations should be irrelevant. That is the whole point of an API/protocal - a description of how things should talk to each other even for different implementations.

I don't see how one implementation helps here - that one implementation still needs APIs for the applications to talk to. The problem is not that there are different implementations but maybe that the wayland protocol does not cover enough of the API space needed by applications. Some of which are addressed by things like the xdg-desktop-portal.

The issue with X11 is that it got big and bloated, and unmaintainable, containing useless code. None of these desktops use that useless code, still in X from the time where 20 machines were all connected to 1 mainframe.

I don't think that is very fair to say. From what I heard, the X.org code as in the implementation of the protocol and its extensions is actually of very high quality, so it can be maintained. The problem as you correctly describe is the design and the resulting protocol with its extensions which don't fit modern needs.

It's also not like theoretically multiple X11 servers implementing the X Window System couldn't have existed simultaneously, it was just too much effort regarding the complexity of the protocol. In fact, for a short time, two different implementations existed: XFree86 and the X.org server. Granted the latter was a fork of the former, but they were independent projects during the time of their coexistence.

I find it hard to understand what I'm supposed to address from your monologue, but I'll go with one thing that stuck out to me.

What does this have to do with app developers? GNOME, Plasma, Wlroots, and Smithay use the Wayland protocol. If app frameworks use the Wayland protocol, then they're compatible with GNOME, Plasma, Wlroots, and Smithay. Apps won't work if GNOME, Plasma, Wlroots, and Smithay were compositors with their own, separate, incompatible protocol. Or the Wayland protocol in that hypothetical world is so poor that Wayland compositors deviate so much from each other that app frameworks must support each compositor individually.

xkcd describes this problem quite well

So why not just use the lean and maintainable wlroots

wlroots can't be used (comfortably and idiomatically) in Rust because it's too hard (if not impossible) to provide a memory-safe interface for it.

we can move to another implementation of the Wayland protocols.

So unfortunately this has already happened.

What i wonder about, why do compositors have to handle Keyboards (again)? Wayland does and X did. Shouldn't that be separately handled?

I love the idea of Wayland, but it only finally actually booted for me onto the desktop earlier this year (on Manjaro KDE). But it still randomly freezes for about a full minute, quite a bit. I am keen to move to it as my compositor hangs on X11 for some odd reason on KDE every time I try to do a rectangular area screenshot with Spectacle (mmm just realised it is also for around a minute - maybe I do have some other underlying issue), or when accessing the Compositor menu option. But X11 is still otherwise rock solid for me.