Right. Version numbers can't work, which is why Nix avoids them and organizes packages by the hash of their full dependencies instead - thereby making every pac

Right. Version numbers can't work, which is why Nix avoids them and organizes packages by the hash of their full dependencies instead - thereby making every package unique and immutable - reliable upgrades and downgrades can be performed because there's no "unfortunate" side effects that can be introduced - such as the example I gave above where you need to introduce new packages "A10" and A11" instead of "A", because you need both, and you already mutated "A" to mean something other than it originally meant (hence, rollback is a breaking change with most PMs). If we're looking for a way to "communicate" working DAGs for other people to use, I think the best place to look is existing in DVCSs - submodules/subrepositories basically provide what we need - because every commit to a repository using submodules refers to exact commits in exact branches of the submodules. If we managed to use git ubiquitously in such way that all of our dependencies were submodules, and in turn, those dependencies used submodules for their own dependencies, we have the entire DAG that would otherwise need to be written as Nixpkgs. This also solves the version explosion issue, where there could exist dozens or hundreds of derivations of the same packages with slightly different configurations, bug-fixes or other changes - because a "derivation" just becomes a specific commit in a specific branch of a repository at a known URL, and to utilize the different version from a dependent software, you just update the submodule and point to the desired head.