Isn't this what the badges.maintenance field in Cargo.toml is for? If you set badges.maintenance.status = "deprecated" and publish a version then crate indexing sites will pick up on the crate being deprecated.
As an example, here is how pros-sys, a deprecated sys crate for libpros, looks like on lib.rs: Pros-sys 0.8.1 [deprecated] // Lib.rs (notice how the header has "deprecated" and the crate name is crossed out).
And here are the lines in Cargo.toml which I used to mark it as deprecated.
Since the official Crates.io site doesn't show badges set in Cargo.toml (even though they are part of the spec), I also added an "Unmaintained" readme tag when I was deprecating pros-sys to make it clear for viewers on that website.
Most of the time, we only want to deprecate some versions of a crate. For example: A serious security vulnerability suddenly found in the old version. Or the old version has some serious performance pitfalls. Or more.
It also requires a new version to be published. Making a new release to update the status to "deprecated" or "abandoned" seems like a lot of unnecessary churn (even just considering Dependabot PR noise).
In this case that version really should be yanked: I do not want that version to end up in my dependencies without wizardry-level commands. If the vulnerability can be qualified as “serious” then yanking is not “way too alarmist”. (It could be a bit too much if the vulnerability relates to a mostly-unused feature of the crate, but this was not implied in your previous message.)
Well, my wording can be improved. But saying "serious enough to deprecate but not enough to yank" is kinda wordy. The point is, a blanket badge cannot serve as deprecating of selective versions.
Another perspective on deprecating versions is "what versions are supported?".
One way to have our cake and eat it too with MSRV is if people using older compilers take on the cost of also not having the latest versions of dependencies. I'd love to say "clap's MSRV is 10 versions back but is supported through previous minor and major versions getting critical fixes, driven by those who need them". The challenge is people will just see "old clap" and not know if it is supported or not. Having a way to track version support policies for users would be great.