There are many cases where binaries compiled on older systems will not work on newer, despite no differences in APIs - this is due to Glibc going for "versioned symbols" instead of versioning ABI.
And of course there are cases, especially if you have C++ somewhere, where you have to bring not just glibc but also ld.so from the ancient system... (There's a big chunk of such libs packaged together to run Loki games ports on recent distros)
At least in my experience this has never been an issue with C programs (or C++ programs after getting the older C++ stdlib). I have a collection of old Linux game demos from late 90s and early 2000s and i tried them a couple of years ago in a modern distro and most of them worked (i had to use the oss-to-alsa bridge though). The games that didn't work were because of missing libraries that the distro didn't include, like -IIRC- Shogo needing Qt1.
Note that glibc also has non-versioned symbols. Versioning was introduced much later than the binaries i've mentioned i compiled with 1998 Red Hat were made. In addition the reason behind versioned symbols is to be backwards compatible so older binaries not working on newer systems because of versioned symbols would defeat the entire point of them existing in the first place.
> I have a collection of old Linux game demos from late 90s and early 2000s and i tried them a couple of years ago in a modern distro
Let me point again: I started the thread describing the opposite scenario:
Developing a program and delivering the binaries to the clients, including those who installed the OS on their server farms 10 years ago and not upgrading them, and who expect the binaries to "just work" there too.
That's why Red Hat and "Long Term Support" concepts exists: so that companies don't have to spend more time chasing the latest and greatest and totally irrelevant newest version of everything.
One wants to be able to deliver the products to them too, and avoid developing only on these old system, working around the bugs that were solved years ago.
The resulting binaries should just use what is available in kernel, and that's it. It's a real problem and it should be recognized.
Which results in funky situations where 22 year old binaries run, but a binary that is less than 4 year old can't - because unless you do extra work, you will get versioned symbols linked and you might be unlucky enough to fall out of the window of supported versions quicker than you think (Happened to me ~2013 when dealing with GHC at university, made for some really annoying weekend fixing binaries around)
And of course there are cases, especially if you have C++ somewhere, where you have to bring not just glibc but also ld.so from the ancient system... (There's a big chunk of such libs packaged together to run Loki games ports on recent distros)