I think pretty much every package manager tracks what was installed manually and what was installed as a dependency of something else, so that it's easier to just remove everything that is no longer needed.
When you remove that package, you now also have to change the configuration of your repos to remove the one that it came from, or arrange a vendor change (the best case, with a powerful package manager like zypper), then run an upgrade to get the default one back into place.
What the GP is talking about is how containerized packages eliminate that step during uninstallation.
If a program depends on a specific version of a library that's not provided by the distro (because it's obsolete, vulnerable, too specific etc), it still can be installed by the package manager, if the vendor provides a suitable version within the package. The nice way of doing this is to avoid colliding with the system-provided package either by using a different name or by installing it under a different path. Many vendors do precisely this when offering their packages.
In both cases, it's easy to uninstall the no-longer used dependency - on the first case, it'll be marked as automatically installed and can be removed with a cleanup command. On the second case, uninstalling the package should also remove the library.
There are some more traditional (in the sense that libraries are always shared by default and no containerization is required for packages to work right) package managers that extend the kind of isolation you describe (‘installing [special or patched versions of dependencies] under a different path’) to all packages, namely Nix and Guix. These package managers also make it easy to do things like take a package definition from somewhere else and rebuild it with just one or two dependencies modified without redefining the whole package, or alternatively take such a package definition (perhaps originally targeted to a different release version of your distro) and rebuild it with all dependencies instead being provided from your current distro. At the same time, since the dependency chains of packages are isolated by default in these systems, it's relatively easy, in case of a special need, to take any package and bundle it and its dependencies into a container for distribution on ‘foreign’ systems. (And for packager convenience, the package collections in these distros may also explicitly include multiple versions of a library in their default package sets in the same way that other distros do, as you describe).
Nix and Guix have their own difficulties and quirks, of course! But one of the things I like about their approach is that their innovation is conservative in a certain sense: it offers more isolation for packages (along with the cross-distro compatibility and potential for bundling that come with that) but preserves the virtues that have been the strength of package management on Linux forever. I would like for whatever really is the future of package management on Linux to share in that.
So I don't think containers are The Way Forward™, although I do think that desktop containers like Flatpak are potentially useful as (1) a step toward more fine-grained permissions for desktop apps in terms of access to files, multimedia devices, and so on; and (2) a way of providing cross-distro packages for applications that (a) have yet to accrue much developer interest from packagers and distro maintainers or (b) are (unfortunately) proprietary.
(Personally, if I really want a piece of software, it's not in the distro I'm currently using, and it doesn't seem especially difficult to package, I will just go ahead and make a package for the distro I'm using. Case (2a) provides a convenient, more managed way for me to evaluate a new program I've heard about without having to package it just to see if I like it.)
