That's equivalent to static linking, but with extra runtime overhead. You can already efficiently ship updates to binaries with something like bsdiff or cougrette, so the only reason to bundle shared libraries in an archive is for LGPL license compliance, or for poorly thought out code that wants to dlopen() itself.

Upgrading a library that has been statically linked isn't as nice as a shared lib + afaik the OS doesn't reuse memory for static libs.

A container image is a tarball of the dependencies.

Yes, but containers also provide more stuff that I might not want to deal with.

The OS can be smart enough to load identical libraries once. But it requires them to be the same file. This can be achieved with Docker image layers and sharing the same base layer between images. It could also be achieved with content-addressable store that deduplicated files across different images. This would be helped by container packaging system that used the same files across images.

Page sharing can also depend on the storage driver; overlayfs support page cache sharing and brtfs does not.

That's basically what OS X does with bundles.

jars already support this.

yes, I think we should have the same capabilities in a language agnostic way.

Signed jars are a little painful to use (you can't easily bundle them), but that's a minor issue.