If you build an executable that works on a current version of Windows, that executable will probably work for many years on newer versions of Windows. Microsoft works very hard to ensure this.
With Linux, there's an expectation that you'll have the source code to the software you're using, and therefore breaking binary compatibility is OK as long as you maintain source compatibility. This leads to distros phasing out old library versions and periodically breaking things that used to work.
For someone using Linux as a gaming platform, this is a problem, because games tend to be distributed only in binary form. It makes Linux ports look bad when they break, but I have a feeling it would be more productive to try to solve this problem generally, rather than expect everyone to update their ports.
Are there any distributions that try to preserve binary compatibility, not necessarily by keeping all old versions around but at least keeping old sonames, such that a binary that works with release n should also work with release n+1?
The closest thing I can find is Valve's "Steam Runtime", which is a binary compatibility layer only available to programs distributed through Steam.
Best Answer
Basically this boils down to: you can't keep binary compatibility and introduce new features, since these things go directly against each other in most aspects. If you introduce major new features you in the end have to change the ABI (usually shortly after the changes in the API). Now, you can have versioned symbols (like for example Glibc has), but this makes the libraries grow in size (and may also incur some performance penalty while loading a binary into memory) and developers certainly don't want to keep it in general libraries (the legacy code contains bugs that nobody is interested in fixing).
The usual way to go around this on distribution side is twofold:
do not change versions - this is typical for Enterprise-grade distributions like (in alphabetical order) RedHat and SUSE, as well as for some others (Debian, Slackware, Ubunty LTS and probably their clones).
allow installation of various versions of a library at the same time.
On the application distributor this is handled in the same way as on windows: stuff everything needed into the distribution package. Yes, this is the way it is often done on Windows - this is also one of the reasons for typical Windows system usually having several times higher disk space requirements than Linux with the same functionality - the applications are simply sharing only very little among themselves and have their own copies somewhere. You can think of it as of every GTK/Qt application coming with its own GTK/Qt stack. It can have some advantages but disadvantages are also plentiful. For example from security point of view it is a nightmare in TechnicolorTM. If the binaries are statically linked, it's even in FullHD.