ISTM that anything which lets you install multiple versions side by side will require each version to have pinned versions of dependencies, transitively, until

ISTM that anything which lets you install multiple versions side by side will require each version to have pinned versions of dependencies, transitively, until it's very close to the dominant node, which ultimately is the OS API, which in turn, done right, is backward compatible. You can implement that versioned dependency DAG as a database of versioned libraries etc. combined with a version pinning database; or you can simply use disk space, and keep a copy of every dependency and put each in its own subtree, making the version pinning database implicit in the tree construction. I don't see the latter solution as being intrinsically worse than the former. I don't think there's a real alternative either; the most reliable set of dependencies is the same set as the original binary was built and tested with. (And of course it's not just libraries, but also configs of various flavours, assets, etc. If you didn't use the subtree approach, you'd need to reimplement it in a shim layer to simulate it, in order to package yesterday's applications today.)