That's only one facet of the problem Flatpak is trying to solve (and it's a feature Flatpak will use).

But, there are other considerations. Docker, despite its several negatives, has become popular because it begins to address the repeatable infrastructure needs of a service-based architecture.

e.g. say I have 10,000 servers. I can't possibly manage them all individually. The performance of using something like Kickstart to deploy them would be problematic, and each of them has a well-defined role, so having a pre-defined image (that can evolve over time) begins to make more sense. One of the things Docker got right was taking the concept of a package up a level of abstraction; so now you don't install Apache and a million other things to get your web server deployment...you install a specific bundle of things in a pre-defined image. Maybe even an immutable image that is identical on every one of your several thousand web servers (or containers or VMs, whatever). Being immutable provides some security and maintenance benefits. Being in a compressed/snapshot-able image provides deployment speed benefits and maintenance benefits. Providing dependency management at both the individual package (like RPM/deb) level and at the higher container level is also a benefit. Docker doesn't do anything along those lines (and can't, given it's implementation). This would strap into a configuration management system nicely, as well.

All of it is possible the previous way. I love RPM/yum. I love Kickstart. I love Ansible (or Puppet or Chef or Salt). Those are great tools, and you can build a repeatable infrastructure using them. But, this is another layer of abstraction, and it will enable a lot of cool stuff going forward.

And, soname is still part of the equation. You've got to build these runtimes. You've got to have some way of building and versioning all the software that is in them. And, you're not going to put 30 versions of OpenSSL in a runtime...you just need the latest version with the correct ABI version compatibility for the stuff you're building against it and distributing for it.

Let's assume that a developer wants to distribute a binary build of their application that uses the OpenSSL library that runs on every GNU/Linux system released in the last 5 years. As you might know, OpenSSL releases a new ABI-incompatible version of their library every other year or so, and so there are at least 3 different OpenSSL ABIs / SONAMEs available in the distributions the binary build should run on.

So far the only choices available (edit: for desktop applications) are either static linking OpenSSL, or abandon the idea of distro independent binaries.

With FlatPak, OpenSSL can be bundled in the runtime, so multiple applications can depend on the same runtime and share one dynamic library, and benefit from the runtime getting security updates for the monthly OpenSSL CVEs instead of doing that themselves.

Now you are looking at distro policy, especially the likes of Debian Stable.

If the package manager allows for multiple version of openssl to exist without naming shenanigans, there is nothing stopping a third party package to go on top of Debian Stable and provide the most recent ABI version.

In essence you are looking for technical solutions to policy/politics...