You're description of the versioning issue doesn't make much sense to me, at least assuming you're talking about editions. Editions are guaranteed to be support

You're description of the versioning issue doesn't make much sense to me, at least assuming you're talking about editions. Editions are guaranteed to be supported indefinitely, and different crates can have different editions while still being entirely compatible with each other. So a 2032 compiler should be entirely able to continue compiling the 2018 project, even though the depended-on crate is now using the 2030 edition. The way you describe yanking also seems a bit confusing. If the original project had a dependency that was yanked for security concerns, then the original project was already compromised in the first place. Even then, assuming the lockfile was checked in, then it should still be possible to download the yanked file (plus the compromising code, although the act of downloading a yanked file produces a warning, I believe). If you mean that the project was working fine (no compromise) and then a later version of the dependency was compromised, then no changes are needed at all - the lockfile will always ensure the exact same version is downloaded. If you genuinely think you've found a situation that isn't solved by the edition mechanism, or by the judicious use of lockfiles for all projects, then I'm sure the Rust team would love to hear it (although I can't speak for them). But from what it sounds like, you're describing issues with the Node ecosystem and assuming they also apply to Rust, despite a number of differences in how the two ecosystems operate.