[requested to file a RFC in https://github.com/rust-lang/cargo/pull/7188, so opening a pre-RFC thread here first]
Cargo supports alternate registries, which allow for packages from multiple sources (under independent namespaces) to be included in the same project. Currently, these work by specifying the URL of a git repository, which includes a configuration file naming a download server. This works well on many desktop use cases, but when integrating with existing build systems things can get more complex - in particular, they may have their own ideas about build reproducibility which do not allow access to external servers, which control which source or crate versions are visible to a build, and have their own version management rules which do not play well with Cargo.lock files.
With crates.io, these problems can be dealt with by using source replacement; a pre-build script can examine the Cargo.toml and/or Cargo.lock files, resolve them based on a frozen snapshot of crates.io, and download them via the external build orchestration framework. However, it does not appear possible to do this with alternate registries - as far as I can tell, they require a HTTP server for the actual download of the crates, at a minimum, and do not support source replacement entries.
While it would be possible to implement source replacement rules for alternate registries, this is a bit strange - we'd have to specify a bogus URL in the [registries] section, only to replace it with a local-directory source replacement rule. Therefore, I propose simply allowing the alternate registry to be directly specified using a local-directory statement in the relevant [registries] section.