Sure, you could dlopen() different SONAMEs until you find one that works, and now you just have to somehow deal with the structs having changed between versions, and the prototypes of functions not being compatible, so yes it's technically possible but nobody is going to bother

The idea isn't to open dynamic libraries randomly but to open dynamic libraries you explicitly know they provide the newer than 3 years functionality you want.

It isn't some fantastic never-seen-before concept, it is how applications on Windows can use new APIs from Windows 11 while still running on Windows XP or how OpenGL programs can use APIs from OpenGL 4.6 while being able to run on drivers that only expose OpenGL 3.1.

Yes, and for the reasons I expressed it doesn't work that way for most libraries under Linux.

OpenGL worked on Linux last time i checked (a few minutes ago).

Linux isn't some special case that makes this impossible, the only reason for this to not work is libraries themselves not making it possible. But the blame lies with the libraries not with Linux.

Like I said, it's technically possible and that is (outside a very small number of well-defined outliers like OpenGL) entirely irrelevant in terms of whether it's practically possible. Even if we rewrote every library now to have mechanisms to make this easier, it wouldn't help for any of the older versions that don't do this and which are already deployed everywhere.

Of course it is practically possible, as long as the developers care about backwards ABI compatibility - the issue isn't if it is possible or not (it certainly is as actual existing APIs and libraries show), the issue is library developers breaking their libraries' ABIs.

But that doesn't mean it isn't possible to do something like this, it means that you have to stick to libraries that do not break their ABIs. And this has absolutely nothing to do with Linux you brought previously, everything i mentioned works on Linux and any other OS that supports dynamic linking and has ABI backwards compatibility for the applications that run on top of it.

RHEL 8 doesn't ship with GTK 4. How do I ship an application that uses functionality that only exists in GTK 4 if available, but falls back to GTK 3 if it isn't? If libraries had been written with this in mind (like OpenGL was), then yes, there'd be a path to doing so. Libraries on Linux could work in the way you suggest. But, for the most part, they don't.

Well yes, you basically come to what i've been writing about so far: the issue is with libraries like GTK 4 that break ABI backwards compatibility. It isn't the issue with Linux, Linux doesn't break ABI backwards compatibility - if GTK 4 didn't break their ABI you could use the GTK 3 API as a baseline for your application and dynamically load the new GTK 4 stuff (and as a bonus you'd get any inherent improvements that might be there in GTK 4 that are exposed through the GTK 3 API, like how -e.g.- applications written for WinXP get the emoji input popup on Win 10 even though that didn't exist during WinXP's time).

The REAL problem is libraries breaking their ABIs, not Linux itself.

If you're defining Linux as a kernel, then yes, the kernel does not impose any constraints on userland that would make this impossible - and I never said it did. If you're defining Linux as a complete OS, then the fact that it's conceptually possible for libraries to behave this way is irrelevant; they could, but they don't, and any solution for distributing apps needs to deal with that reality rather than just asserting that everything else should be rewritten first before anyone can do anything.