>Any UI program that you write will work just fine on KDE, GNOME, DWM, etc

But which versions of which libraries do you target? Every distribution has its own menagerie. There is no well-defined "Linux platform" like there is with Windows (https://docs.microsoft.com/en-us/windows/win32/api/).

If your software is FLOSS, that's an integration problem for distro maintainers to solve and it hinges on said libraries being versioned properly. The bigger distros usually have 10,000+ packages and those are downloaded, installed and updated automatically which cannot be said of almost all Windows and OS X software. Really, only Android and iOS offer a similar experience.

If your software is proprietary (or not popular enough to be found in most repos), there's always container technologies like Snap/AppImage/FlatPak/etc.

As a Windows dev I find both of these to be vastly superior to the standard Windows practice of shipping every DLL that's not in system32 alongside your executable, on top of whatever VC++ redistributables and/or .NET framework might not be present on the system.

Just static link? Or do what windows software does, so ship dynamic libraries with your application. I do not see the issue.

> There is no well-defined "Linux platform"

There actually is! https://en.wikipedia.org/wiki/Linux_Standard_Base

Core libraries like glibc and Xlib are pretty well defined. You need to ship your own copy of the widget library of choice, but that isn't a big deal. You could even ship an Xlib copy and rely on the fact that there is an X server speaking the same protocol. It's all perhaps a bit messy, but it works.

That is only true on X. With the wayland protocol, the DE also becomes the display server. And because of barndoor sized holes in the standard wayland protocol, apps will either have enormous testing effort or be limited to a DE or two.

And that's why wayland will never replace X

Most programs use existing libraries like SDL, GTK, QT, etc, which handle wayland integration on their part.