This isn't necessary. If you're not going to load both versions into the same process, they can overlap symbol names. This is how Linux distro version upgrades work: the system installs libfoo2, then upgrades binaries that use libfoo1 to versions that use libfoo2, then removes libfoo1 when nothing needs it any more. At all times, the system is in a working state; any given binary will load either libfoo1 or libfoo2.

The trouble is that Linux distros tend not to want to provide more security support for libfoo1 than they have to, so if you have software that still requires libfoo1, the easiest approach is to use a container/chroot/VM/whatever with an older distro release, possibly from a different vendor, that's hopefully still under security support.

(If you do care about loading both libraries into the same process, you need symbol versioning / two-level namespaces / direct binding / whatever your ld.so wants to call it, which means that every reference to a dynamic symbol specifies which dynamic library the symbol comes from. The names themselves remain unchanged, but they're referenced by a tuple of library and name. This works. Again, I've shipped software that would crash horribly if this didn't work.)

> Both the software developers and the package managers never intended for incompatible software to be installed at the same time.

I'm not sure that's true for software developers: I can't imagine that, say, the OpenSSL developers do their work by replacing their system OpenSSL every time they recompile. They already know full well how to test an OpenSSL in ~/src/openssl and keep it separate from the one in /usr/lib, without using chroots.

It's true for package managers, but that just means that package managers are failing at delivering a thing users want.

In particular, forcing upstream software to follow conventions and building all software the same way, and patching things as necessary, is the entire job of a distro. If two versions of a distro package conflict, that's because the distro chose not to make them coinstallable. If only one version of a library is available in a distro, that's because the distro chose not to make other versions available. They might have reasons for this (e.g., security support effort) but none of it is fundamental impossibility.

(Also, if you mean B1.1 in a semver sense, or equivalently a libb.so.1.1 sense, upstream is promising that it's backwards-compatible with B1, such that A can dynamically use B1.1 despite being compiled against B1. If that's not true and B1.1 is ABI-incompatible with B1, either upstream or the distro needs to rename B1.1 to B2 / rename libb.so.1.1 to libb.so.2.)

> Devs get to pretend they know how to deploy software or manage systems

I submit that the only valid measure of whether you know how to deploy software or manage systems is whether systems get deployed or systems get managed.