Maybe we could introduce a finer mechanism so the owner of a crate can mark some versions as Vulnerable, Broken_API, Major_issue, Unmaintained, ... with an issue id (like a rustsec id) and a comment. A warning would be raised if a marked crate is used. I'd advocate that crates with vulnerabilities and broken api might still be treated as currently yanked crates. You would still be able to ignore an issue with a parameter like ignore="RUSTSEC-2023-0666"
But right now, yanking is the only mechanism available to reach the users than does not use external tools when there is a problem. If we want to deprecate yanking, we need to introduce a better feature as replacement first.
It doesn't make sense to put "ignore yanking" options in Cargo.toml. The point is that you don't know which crates should ignore yanking until they're yanked, and you need it most on legacy and historic code anyway, where you can't change the Cargo.toml.
It should be a flag on cargo call itself. Perhaps writing a special cargo tool to ignore yanking is the best solution. It doesn't look like we'll get any compassion around here.
I think you have an opportunity to focus your argument here better.
Thank you for this comment --
I want to try to give a more concrete example, or series of examples, where I think that yanking can cause cargo to do something undesirable and where the amount of stuff I have to do to get it not to do that grows larger and larger.
I haven't had time to put together such an example in detail, but I think I will have time later this week. Thanks to everyone who has commented for their interest in this issue.
(This is the epitome of bikeshedding the naming of a small part of something where the whole design is in question, but IMO it should be --allow-yanked since "ignoring yanked crates during version resolution" is the default (and for that reasoning I used it in cargo-dl)).