>This is about the needs of users and developers.
I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them.
>That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it
I don't know what you mean, this feature was never supported in GNOME's Wayland session. It never had that existing behavior, the decorations were a private KDE extension that was picked up by mir and wlroots and then much later put into wayland-protocols. It doesn't make sense for KDE to implement a feature and then declare GNOME to be broken because some others copied that feature but GNOME didn't.
>meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be
I personally like Arcan but according to the developer it's not trying to solve all the same problems as Wayland or X11 even though it may be compatible with some apps. I don't believe GNOME and KDE are going to rewrite their window manager in Lua for example.
>What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date.
The API and ABIs for those libraries are stable across major versions, they guarantee that. All Linux distros would see major breakage if they didn't, since they don't necessarily recompile the applications along with library upgrades.