Linux makes an explicit effort to not break userspace.
I had a weird experience where I had to use a device stuck on a 2.6.x kernel, and I was able to run a modern distribution on top of it.
Similarly, running old userlands on new kernels works just as well.
The issue with backwards compatibility isn't with the kernel, but ensuring that whatever you want to run is compatible with the surrounding userland environment. Dynamic linking can break backwards compatibility, for example, but that's an issue above Linux.
While you are technically correct, that turns it into a bit of an apples to oranges comparison with Windows because most of what we consider to be the Windows operating system would in the Linux world live in userspace. Which means that when we're comparing the user's experience of an average Linux distribution with Windows it's definitely fair to say that Linux doesn't prioritize backwards compatibility.
Just yesterday, I purchased a game from GOG where the Linux build cannot start, owing to who knows what expected platform profile. Maybe, technically, I could have fixed the problem. The Windows build worked without issue in Wine.
Assuming you can go through the dependency hell, because you can't use old packages on a new distro - so in most cases you have to compile by source... I've tried to run XMMS and suffered a lot.
Distrobox[1] automates the process of installing popular distros released in the past decade or so in containers.
For games in particular, Proton[2] (a game-specific Wine fork) or one of the Steam container runtimes[3] (for native Linux games) might also be worth a try.
For a non-Steam game:
1. Install and run the Linux Steam client (Steam account required).
2. Add the game to the Steam library: "Add a Game" → "Add a Non-Steam Game…", choose game executable.
3. Right click on the game, choose "Properties" → "Compatibility" → "Force the use of a specific Steam Play compatibility tool", and choose a version of Proton or container runtime (the most recent non-experimental version is probably a sane default).
4. Make sure the selected Proton or container runtime version is installed. These should be available for installation from the Steam library by default. If you can't find them, click the dropdown above the search box in the Steam library, make sure "Tools" is checked, and make sure the "Show only ready to play games" option ("play" arrow in a circle icon to the right of the same dropdown) is disabled.
Indeed, and with tools like Distrobox nowadays, it really is realistic to have a Fedora 40 host system running apps compiled for Fedora 17. In related news, being stuck with RHEL on the host has gotten a lot less painful. Desktops are finally really benefitting from containers (including flatpak)!
I had a weird experience where I had to use a device stuck on a 2.6.x kernel, and I was able to run a modern distribution on top of it.
Similarly, running old userlands on new kernels works just as well.
The issue with backwards compatibility isn't with the kernel, but ensuring that whatever you want to run is compatible with the surrounding userland environment. Dynamic linking can break backwards compatibility, for example, but that's an issue above Linux.