Looks like directory sources are also intended to be immutable, so from what I can tell the only way to tell cargo that a dependency may change without changing its version is through a path dependency. Or by automagically injecting a [patch] that replaces the registry dependencies with path ones (though that runs into issue 5539).
Since path dependencies require the user to know what path to specify, that suggests to me that any build system that wants to manage dependencies whose checksums may change must either come up with a well-known scheme for how those paths should be constructed, or we need some kind of "collection-of-paths source" (which I was hoping directory could act as).
It sounds like path dependencies pointing to a magic path that only exists inside the build jail is where you should be driving here: path = "/internal-rs/foo"
Perhaps I missed it in the discussion, but have you considered having the package registry always append its own additional version component beyond what's specified in Cargo.toml? Something like:
0.0.0 => 0.0.0.0 (followed by 0.0.0.1, 0.0.0.2, etc)
1.2.3 => 1.2.3.0 (followed by 1.2.3.1 etc)
1.0.0-pre.1 => 1.0.0-pre.1.0 (not sure that one's valid)
This would allow for auto-incrementing versioned rebuilds with unique checksums, which I think would play more nicely with all the existing tooling which expects there is one-and-only-one checksum for a given version.
Unfortunately I don't think that'll work. I believe cargo only considers major.minor.patch, and beyond that you can only specify pre-releases, which are considered unordered.
Auto-generating version numbers also gets complicated once you have many developers. If a build version is generated locally, it might not match what other people get on their host, which would make lockfiles hard to share. If we require a centralized version assignment, then offline builds become impossible.
