Earlier quoted context omitted.
They exist but they’re in the minority. Compare this with the Linux world, where userspace compatibility between one major distro release and the next, 12 months apart is very much a roll of the dice.
This is true. To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this. But if you want to use... anything else, then it's unlikely to work at all unless you are very specific about your target. There isn't one company deciding that glibc or mesa or whatever is binary backward compatible on every ker…
This is frankly the opposite of how it should've been. Who cares that the kernel ABI doesn't change from release to release? As an end-user, I couldn't care less. Even as a developer I care very little indeed, because I'm not writing drivers. I'm almost never programming directly against the kernel's interface but rather using my language's standard library, which is already an abstraction over the kernel interface.
Platform vendors (this includes distro maintainers) should recompile and re-package libraries for each new ABI in each OS release, done. End-users won't ever notice, they can run their applications portably because the user-mode library ABIs haven't changed... Which is what Win32 has done, and what glibc has consistently failed to do.