In security perspective, Yanking a crate on crates.io very better and block the name from attackers or threat actors, reregister deleted crates names and host malicious crates that harm users and users think just the dev it project back working, that is Supply Chain risk, proposals of deleting it can cause some supply security risks, that why i'm not accepting the RFC.
Since a yanked name cannot be registered, An attacker cannot register a crate with the same name as the yanked crate
But here is an idea: when a crate is deleted and after some time (years preferably, not months), someone re-register it, what if existing Cargo.lock would be reported as incompatible? Using a generation counter to prevent the ABA problem.
Like, every time a crate name is reused, it gets an unique name _unique_cratename_N where N is an increasing counter (crate names with this pattern get prevented to be registered). In Cargo.lock, whenever a crate was mentioned was cratename (like all lockfiles today do), it gets interpreted as _unique_cratename_0, which prevents building if the crate were re-registered (since the new crate will be called _unique_cratename_1). But whenever new code depends on cratename, Cargo will generate a Cargo.lock that refers to the right generation counter.
This should probably not be required if the crate being is very new, has no downloads, has no dependencies in crates.io, etc.
There's a problem with this though. This scheme only works with new Cargo - older versions of cargo would be permanently prevented from depending on deleted crates that were later re-registered. (maybe there's a variant of this idea that could accommodate older versions of cargo too)
Instead of renaming the crate, there could be a generation field in the registry and lockfile. Newer cargo will check that the generation matches while older cargo will ignore it in the registry and need the lockfile to be regenerated anyway due to the lockfile version being updated.
I think there should be an option on crates.io to forbid new releases which are semver-compatible with existing crate releases (maybe with some warning for downstream users). You could use it before transferring ownership, thus preventing new owner from publishing malicious patch releases which would be consumed automatically by downstream.
Those solutions seem to revolve around the same idea:
In one case, crates are versioned by generation.major.minor.patch where generation is implicit in Cargo.toml and explicit in Cargo.lock.
In the other case, crates are versioned by major.minor.patch and major acts as an approximation of generation. During crate deletion, the next generation is the next major version.