You're forgetting about one common case where libraries are replaced.
This is security vulnerabilities. If your application depends on a common library that had a vulnerability, I can fix it without you having to recompile your app.
With GLibc or X libraries a vulnerability there would result essentially requiring reinstallation of the entire OS.
You could but you would be doing yourself two disservices by trusting vendors that aren't providing security updates for dependencies in a timely manner and running applications on top of dependencies they haven't been tested with.
Vendors could ship applications with dependencies and package managers could tell which of those applications and dependencies have vulnerabilities. This would clarify the responsibility of vendors and pressure them to provide security updates in a timely manner.
One big obstacle is that it's fairly common for vendors to take a well known dependency and repackage it. It's difficult to keep track of repackaged dependencies in vulnerability databases.
You seem to be assuming rebuilding is possible. What about the (still very useful) proprietary binaries from a company that hasn't existed in a decade? What about the binaries where the original source no longer exists?
I say that presents market opportunities. Every piece of technology faces a time of obsolescence.
If the original source no longer exists and rebuilding is no longer possible then replacing dependencies is no longer feasible without manual intervention to mitigate problems. ABIs and APIs are not as stable as you'd think.
> Every piece of technology faces a time of obsolescence.
That is true for most technologies that experience entropy and the problems of real world. Real physical devices of any kind will eventually fail.
However, anything build upon Claude Shannon digital circuits do not degrade. The digital CPU and the software that runs it are deterministic. Some people see a lack of updates in a project as "not maintained", but for some projects that lack of updates means the project is finished.
> obsolescence
What you label as obsolete I consider "the last working version". The modern attitude that old features need to be removed results in software that is missing basic features.
> replacing dependencies is no longer feasible without manual intervention to mitigate problems
This is simply not true. Have you even tried? I replaced a library to get proprietary software working last week. In the past, I've written my own replacement library to add a feature to a proprietary program. Of course this required manual intervention; writing that library took more than a week of dev time. However, at least it was possible to replace the library and get the program working. "Market opportunities" suggests you think I should have bought replacement software? I'm not sure that even exists?
> ABIs and APIs are not as stable as you'd think.
I'm very familiar with the stability of ABIs and APIs. I've been debugging and working around this type of problem for ~25 years. Experience suggests that interface stability correlates with the quality of the dev team. A lot of packages have been very stable; breaking changes are rare and usually well documented.
This is security vulnerabilities. If your application depends on a common library that had a vulnerability, I can fix it without you having to recompile your app.
With GLibc or X libraries a vulnerability there would result essentially requiring reinstallation of the entire OS.