Introduction of the msrv flag or Rust version cfg would be breaking by itself, so it can't help existing Rust/Cargo versions, but only solve the problem in the future. This means that the best time to release it was many years ago, and now is the second-best time to release it.
It does need some adoption, but because Cargo compiles crates starting from the leaf dependencies, it only needs adoption in a few popular leaf crates. I estimate it can be literally as little as the top-10 worst-offending crates to make an impact on the entire ecosystem.
I also like patch-in-config; but overall I feel that patching needs to support behavior more similar to global renaming. How patching currently works is still somewhat unusable (I've found) while working on e.g. crate sapio for my patched versions of crate rust-miniscript that add some slight new features. Every time rust-bitcoin updates, I need to go around and fix all my patch versions. And I don't have control over the library user's final bin crate (I guess I can document which patches they need? But the main repo updating breaks my build). As such i've just forked the rust-bitcoin crates and will upstream at some point and un-fork, and my library requires the use of something like erased_serde to integrate with other libraries using mainline rust-bitcoin, far from ideal.
It's a slightly different issue but maybe you know of some similar unstable features that would fix this too.
This probably isn't the best place for that discussion I would bring that up in the tracking issue for patch-in-config, or raise it as a separate feature request.
Oooh, now that is an interesting one. I agree with you that this could be very helpful in leaf crates, and it's implementation (or rather, it's interface) is also fairly stable as far as I've been able to tell. I think I have two concerns with it though:
It's not clear if it has "big fan-out". That is, making the feature available under preview on stable doesn't immediately give benefits to lots of users. At the same time, you're totally right that adopting it at the leaves might clean up code substantially and improve performance, which is a win. I'd be curious to hear the various teams' thoughts. My most immediate take on it is that it's a little too risky to preview, since if many leaf crates start adopting it, it suddenly becomes difficult to change/remove the feature without major breakage on stable, which is the whole reasons unstable features aren't generally available on stable in the first place.
While you're right that the feature does make a difference at the leaves, I'd be concerned that if we offered the feature in some way on stable, libraries that aren't leaves might start making use of them. And then we get into the game of "unstable stable" that we really want to avoid. Here too, if the feature was later removed or changed, it might cause huge breakage, which is the reason "No cascade" exists as a requirement.
I would bring that up in the