Thing is, just last month i wanted to play an older game that for some reason was linked against Gtk1. And pretty much every application made with Lazarus today is linked against Gtk2 (as the Gtk3 backend is still in a very prealpha state) and i'm sure there are other similar situations. And as you can see with this book, people are still working with Gtk2.

At this point it doesn't matter that it was released 17 years ago, what matters is that there are programs using it.

Honestly, i can see Gtk1 to Gtk2 breaking compatibility since they probably did some blunders and all and it wasn't very long lived anyway, but Gtk2 to Gtk3 should have kept backwards compatibility - GUI libraries are important foundation for a platform and breaking changes breaks every application that relies on them. Instead what the developers did was not only break Gtk3 but not even try to design an API with Gtk3 that would allow Gtk4 to be backwards compatible.

It is frustrating if as a developer you want to ensure your program keeps working in the future and have the foundation it relies on sabotage you. I can release a Win32 application today and i'm certain that if people are still using x86 Windows desktops, it will work in 20 years. Hell, chances are it'll still work in Linux thanks to Wine - whereas the only way i'd get the same sort of compatibility with a "native" UI library would be to write my own toolkit and use X11 directly (and even that assuming Wayland developers wont have convinced everyone to drop X11).

Sometimes i'm just considering to just target Win32 for my stuff and tell people use Wine for Linux and macOS, it'll be more likely to work in the future than any native UI library.

If the GTK1 based game had bundled its dependencies, it would have worked today as well. I think better solutions for that is the way going forward, not requiring devs to maintain compatibility forever.

Expecting every application to bundle all shared libraries it depends on is absurd, it invalidates all the benefits shared libraries provide - like them being shared with other programs, having shared updates and of course new features. As an example, if Gtk3 was backwards compatible with Gtk1, the game not only would work but the UI would be a native client for Wayland despite the game being released a decade before Wayland was a thought at anyone's mind. And to stick with games, you can see another good example why bundling shared libraries is a bad idea: old games that use SDL often need their SDL copy replaced with a new one to work since the old one is using methods that in the meanwhile were invalidated (e.g. using OSS instead of ALSA).

Outside of games, for software that touches the Internet you probably also want libraries to get shared security updates.

And of course having to bundle 50+MB of libraries and data (themes, etc needed by a GUI toolkit and any other data by other libraries) for a small executable is a ridiculous idea by itself.

No, a desktop system should provide some minimum functionality that desktop applications can rely on and keep that functionality stable so that application can keep on working.

I'm only expecting applications that don't update their code in 10+ years to do so.

Systems like Flatpak have a framework system where it is possible to have a shared runtime of dependencies that multiple applications can use. A GTK1 runtime could exist (or maybe does?), for example.

Yes, Flatpak sounds like it solves the compatibility problem (although it remains to be seen in practice what issues itself might have) but it still is half the solution: a Gtk1 could exist, but since that Gtk1 runtime is still the abandoned Gtk1 libraries (which were abandoned because Gtk2, Gtk3 and now Gtk4 decided to break backwards compatibility), it doesn't provide any new functionality and/or fixes to programs linked against it. In contrast in Windows, since Win32 is both backwards compatible and continues to get developed, if for example i use a program from Windows 95 that uses the common file dialog, i still get to see the overlay icons from my VCS extension or the compressed file status. On the other hand Gtk1 would still show the old Motif-like open dialog that was written back in the late 90s.

Or perhaps more fitting to modern Linux desktop, Gtk1 and Gtk2 will not support Wayland nor any new functionality introduced for scaling (did you know that, despite common narrative from Wayland fanboys, X11 already provides the necessary functionality to implement per-monitor and even per-window scaling with pretty much 99% of the same code that a toolkit would need for Windows 8+ scaling, that is most likely already written? It only needs some cooperation from the window manager and this sort of code could even be implemented for XWayland.... but it needs a bit of modification from the toolkit's side too and while it could be done for Qt5 and perhaps Gtk3, it'd need Gtk2 and especially Gtk1 to be worked on, which wont happen - on the other hand, if Gtk2/3/4 were backwards compatible, all programs would benefit from such new functionality).