Err, their solution is the one i lay out in the second paragraph, where foo 1.0 becomes foo0 1.0, and foo 1.1 becomes foo1 1.1 simply to get around package manager limitations.

That is where the extra workload is coming from, the need to juggle effectively two package trees, and the patches for each.

If instead the manager was properly able to handle multiple versions, they could all be named foo, and the manager would be able to traverse the tree and see if foo 1.0 could be discarded or not based on the dependencies listed in other packages.

You get something of this nature in Nix (though they take it one step further) and Gobolinux, by using the directory tree as the final arbiter.

On Gobolinux you have /Programs/name/version, thus installing foo 1.0 would end up in /Programs/foo/1.0, while foo 1.1 ends up in /Programs/foo/1.1.

Then as long as you have one or more programs installed that need 1.0, you can leave it in place, and remove it when no longer needed.

For sake of compatibility, Gobolinux also have a /lib (along with the rest of the FHS) that contains symlinks back to the individual lib files in /Programs, using SONAME to its full potential.