> But is it just this one application? Let's look at the official runtimes at the heart of Flatpak (org.freedesktop.Platform and org.gnome.Platform 3.36 - as of time of writing used by most of the applications on Flathub).
This is why the idea of "runtimes" is bad at the core: existing applications do not benefit from new features and fixes in the latest version of the runtime. But fixing this means that said "runtimes" (ie Gtk, et al) need to actually give a damn about backwards compatibility, which is certainly not something anyone on the desktop side of Linux above X11 cares (and they want to break X11 too instead of fixing it because "it is too hard to fix it so let's throw everything away and make something new that for some magical reason wont also become hard to fix in the future").
Why the idea of having a standard set of libraries to handle common GUI tasks that are available "everywhere" (in desktop distros at least), just like the C library and X11 library (so far) is available everywhere and can be relied on in the long term (think decades, not weeks) is something that sounds like science fiction instead of common sense is beyond me.
Qt5.x.y might be compatible, but what about Qt4.x.y or Qt6.x.y? If some program is linked against Qt4.x.y it wont get any benefits and fixes from Qt5.x.y and the same will happen with Qt6.x.y.
And TBH i'm not sure if a C++ library can ever be backwards compatible, at least without major major hacks (think like automatically generating a "proxy" library that uses the old ABI to forward calls to the new ABI - i think the only C++ API that ever did something like that is Haiku so that they support both G++ 2.95 from BeOS and modern G++ programs from the same libraries - even then this is easier for them since they're the OS and can decide they'll always distribute those proxy libraries, which isn't something you can rely all Linux distros to do), since C++ does not even pretend to have a stable ABI. I know that the G++ developers are trying to keep things compatible but i'm not sure of the C++ designers care that much.
On the other hand on Windows, just a few hours ago i was playing a recent(ish) game made with RPG Maker 2000, which as the name implies was made two decades ago and yet still works perfectly fine. And i have a bunch of older programs that work fine linking against the latest version of Windows 10's libraries, with all the fixes and new features they've got over the years.
> since C++ does not even pretend to have a stable ABI. I know that the G++ developers are trying to keep things compatible but i'm not sure of the C++ designers care that much.
The Itanium C++ ABI is the stable ABI on Linux, and the C++ standards committee (along with those who maintain the Itanium ABI) cares very much about not breaking the ABI. For example, the C++ committee is not able to make any ABI-breaking changes to the standard library, even where it would be advisable.
> But fixing this means that said "runtimes" (ie Gtk, et al) need to actually give a damn about backwards compatibility, which is certainly not something anyone on the desktop side of Linux above X11 cares [...]
Actually, I'd say hardly anyone above the kernel in Desktop Linux cares. Which is indeed among Desktop Linux's largest issues that will likely never be solved because its culture is unable to even comprehend the problem.
Nah, X11/Xorg is stable. I remember a talk from Keith Packard about a fix in the Xorg font server (which he assumed would not be used by anyone by now but he noticed a bug report from 5 years before he made the fix and he decided that if someone bothered to report a bug then there are some people out there still using it, so it is worth fixing it) where he also mentioned how to ensure that any future change wont break backwards compatibility.
Also personally some years ago i tried to build a small GUI library i was working on at the time under a Red Hat distribution from 1997 and then run it on my 2017 Debian[0] (the colors are off because i didn't bother supporting colormaps) and it worked perfectly fine, showing that X11 (which is the only mandatory requirement the library has, under Linux at least) and of course the C library (the binaries are linked dynamically, not statically) do have two decades of backwards binary compatibility.
It is just everything else that is built on top of that that doesn't work. At least everything else that modern desktops use, AFAIK something like Motif is also binary compatible going back decades (which is how Lesstif worked anyway since it was supposed to be binary compatible with Motif).
"make something new that for some magical reason wont also become hard to fix in the future"
this is really well put. I wish people realized that if they are doing essentially the same thing folks prior did,
they really will end up with the same level of results. Unless they really have identified a magical fix to entropy.
The user-facing impact of switching to git is that committing is faster and you get much better branching and merging. The user-facing impact of switching to Wayland is that you stop being able to run GUI programs over SSH.
This is why the idea of "runtimes" is bad at the core: existing applications do not benefit from new features and fixes in the latest version of the runtime. But fixing this means that said "runtimes" (ie Gtk, et al) need to actually give a damn about backwards compatibility, which is certainly not something anyone on the desktop side of Linux above X11 cares (and they want to break X11 too instead of fixing it because "it is too hard to fix it so let's throw everything away and make something new that for some magical reason wont also become hard to fix in the future").
Why the idea of having a standard set of libraries to handle common GUI tasks that are available "everywhere" (in desktop distros at least), just like the C library and X11 library (so far) is available everywhere and can be relied on in the long term (think decades, not weeks) is something that sounds like science fiction instead of common sense is beyond me.