[hi-v-rocknroll]

This is a "Unabomber"-style prescription to the problem. The problem isn't shared libraries and the solution isn't static linking everything because that's wasteful for repetitive binary code duplicated N times consuming disk and RAM pointlessly. The problem is solved by management and cooperative sharing of shared libraries that don't rely on a fixed, singleton location or only allowing a single configuration of a shared library, but allow side-by-side installations of multiple version series and multiple configurations. Nix mostly solves these problems, but still has teething problems of getting things to work right especially for non-code shared file locations and dlopen program plugins. I think Nix is over-engineered and learning-curve user-hostile but is generally a more correct approach. There is/was a similar project from what was Opscode called Habitat that did something similar. Before that, we used Stow and symlink forests.

[wmf]

allow side-by-side installations of multiple version series and multiple configurations

So now every app requires a different library version and you've achieved all the disadvantages of static linking combined with all the disadvantages of dynamic linking.

[hi-v-rocknroll]

No, you're being unreasonable because that's not the goal at all. The goal is to minimize variations while still allowing the possibility of variations that traditional distros like dnf/RPM Fedora/RHEL disallow without jumping through hoops such as renaming/prefixing or alternate toolsets like scl.