> insist on there only being one version present pr package name

That's a partial truth, at best. It is common for multiple versions of popular libraries to be installed at the same time. The whole of Debian or Red Hat isn't necessarily compiled with the same libcpp or Boost, for example, and that's expected. Some software run on Python 2 and some on 3. The packager would need to make sure they don't conflict, but Linux handles different sonames just fine and as long as you separate module paths you'll be just fine.

No it is not. If you want to install two minor versions of glib side by side, it can be done on the soname level (not to say that it is a smart idea, because Gnome devs are crap at keeping API stable). But it can't be done on the package level without playing musical chairs with package naming to work around collisions.

This is primarily why Debian and derivatives use the so version in the package name. Fedora is designed on the assumption you'll only ever have one version of a library installed and everything is built against it, special cases then get made for compat packages as needed.

Sadly more and more dev time is spent with Fedora as the target, leading to massive myopia. This while Debian has to adopt more and more Fedora-isms because they do no longer have the man hours to go their own way.

Well, even though Debian supports this I rarely see it used to install multiple so's side-by-side. Fedora will let you do it, but the entire development process tries to avoid compat libraries where possible (you are supposed to send a message out to the mailing list if a package you maintain is getting a soname bump so others that depend on it can rebuild during the rawhide cycle, this stops being an issue once Beta hits since versions get locked down).