I don't think glibc maintainers care about compatibility considering their constant ABI breakage. New features? Maybe. But as I've said, this might stop some developers from trying out the new shiny things which I consider a good thing. Or if they want to use it, hide it behind #ifdef and supply an alternative. What this does isn't hold back improvement, it forces writing portable code again which everybody forgot in the last 5-10 years. And I'm getting tired of having to package some random new library from a year ago whose version must be from the last 3 months and the Python version must be _latest_ for a piece of software to even consider building itself. Examples: HomeAssistant, Gitea and much more.

This is also mostly a non-issue for open source software where you can always patch it to work on older libc, or make multiple packages if you are the developer. The developer might not want to do it, but maybe the distro maintainers want to which is also fine. And pre-built binaries without source will always suffer since glibc ABI compatibility barely exists.

@phnt generally I find this kind of problem significantly less of an issue in FreeBSD world which I'm grateful for.

If you compile something for FreeBSD 12, I don't care. I can run it on FreeBSD 15 after installing compat12x or I can just fire up a FreeBSD 12 jail. It will still work. The kernel is always backwards compatible, you just need the old libs