I do think that this proposal by itself doesn't really make any sense. Either the crate author simply doesn't use unsafe, or they objectively need unsafe in an irreplaceable way, or they want unsafe and did all the due diligence to validate that it's sound so there's no benefit to disabling it, or they want unsafe and won't do the due diligence... in which case they probably won't add this cargo feature.
Basically, the same argument as [Pre-RFC] Cargo Safety Rails and Crate capability lists. It's a pretty fundamanetal and general problem with all of the "less unsafe everywhere" proposals we've seen so far.
For this specific suggestion, the only scenario where it would even make sense to me is:
- the soundness of some code is fundamentally unclear even if you've done your due diligence, and
- there's a safe alternative for whatever the code's doing, and
- for whatever reason, the safe alternative is not simply another crate.
Offhand, I'm not aware of a single example of all three. arrayvec is probably worth getting out of your dep tree if you can, but IIUC the separate crate tinyvec already covers the subset of use cases that don't fundamentally require unsafe. Pointer offsetting is probably the single biggest example of "soundness unclear" in the ecosystem today, but it's also famously impossible to do in current Rust without UB anyway, so we're stuck with waiting on a language change there. And so on.