wlroots is self-described as "about 60,000 lines of code you were going to write anyway." It's also a moving target and you'll probably have to retool when wlroots updates.

That seems like a huge burden to carry around, considering that a minimal X11 window manager can be a few thousand lines of code and probably still compiles after 15 years.

wlroots came pretty late so there was a lot of code duplication between Weston/GNOME/KDE before that.

I think that's actually the biggest real criticism that can reasonably be made about Wayland: they ought to have produced something like wlroots from the start.

Weston was only ever intended to be an example, and its monolithic nature meant that it wasn't particularly useful as a platform on which others could build (and this was even more true early on, before libweston).

As a result, GNOME and KDE both did their own implementations - and from that seed grew a host of complaints about things not working in one or the other, when on xorg they had worked more or less the same. The lack of a common entry point for "plumbing" also hurt, and can probably take much of the blame for the initial pain that many faced when first moving to a wayland-based DE.

But, of course, that's only obvious in retrospect. I don't think it was at all clear at the time those decisions were being made originally - in other words, it was a mistake rather than malice.

That helps, but you still have to - at a bare minimum - wire up all the functionality. My pet example is trying out a new wlroots compositor and discovering that it has no way to change keyboard layout because it doesn't use that code from the library yet.