I think that alternative registries should be able to mirror dependencies from other registries (with a potential renaming) and published crate must depend only on crates from its own registry (which could be mirrored from other one). The mirrored crate will have at least the following fields: name, name and registry from which its mirrored, name and registry of the source. The latter two usually will be the same, but it could be useful to allow chains of mirrors. As a consequence non-mirrored crate re-publishing between registries should be heavily discouraged.
In the case of a private company registry they will manually mirror crates from crates.io (and maybe other registries) after source review. One could imagine that some companies will create private registries with payed access and reviewed crates, maybe they will even provide some liability guarantees. Some registries will mirror updates automatically based on webhooks or periodic checks. Of course it could work in other way as well, crates.io can approve some registries as a source of crates to mirror. To make this approval automatic or manual is up to discussion. Personally I think that ideally such source registries must use crates.io sub-domains.
Lets say it will be rand.crates.io, now you publish hc128 to it, which will be automatically mirrored to rand_hc128 on crates.io. So if some crate has in the dependency tree hc128 from rand.crates.io and rand_hc128 from crates.io, cargo will be able to solve version constraints and select a single crate version by using the fact that rand_hc128 is a mirror of rand.crates.io’s hc128. The main restriction will be that mirror versions should be the same as for source. It’s possible to remove this restriction as well (by making registry to return list of hashes which fit a given constraint), but I think it’s not worth the additional complexity.
So if some crate has foo twice in its dependency tree, one foo = "0.2" from crates.io and foo = "^0.2.1 from altregistry.org which mirrors foo from crates.io, but on crates.io the latest version is 0.2.5, but on altregistry.org it’s 0.2.3, then cargo will request versions which fit the relevant constraints from both registries (for crates.io it will be 0.2.0 - 0.2.5 and 0.2.1 - 0.2.3 for altregistry.org) and will select 0.2.3 as the latest one. But if there is a dependency on foo = "^0.2.4", then cargo will use two foo versions 0.2.3 and 0.2.5. Not ideal, but I think it’s a reasonable behavior here.
There is also a question from which registry we should download crates (note that we already know source name, source registry, version and hash of the wanted crates). The most logical option is to use source, but a private company would like to use crates from its own registry. I think the latter case is better solved with appropriate Cargo.toml options (e.g. blacklisting all registries except company owned, or giving it the highest priority).