I don’t think this is a good way to prioritize features. Basically it punishes people who put in extraordinary effort to make their crate work with the existing Stable Rust limitations (e.g. using C to implement things that can’t be done in Rust, or implementing other nasty workarounds). For example, I’d love to see const_fn in Stable Rust. Is the best way to do that to drop support for Stable in my crates and use const_fn now? That’s what this thread is encouraging, and it would make my code prettier (fewer macros in my code simulating const_fn).
Besides counting the crates that use a particular feature, we must also count the crates that don’t use a particular feature. 498 crates using the test feature seems like a lot until you consider there’s over 7,000 crates on crates.io, so 498 is less than 7%. This is the upper bound on the utility of such counting, and that bound is pretty low.
In the case of the test and bench stuff, IMO the fact that rustc-test crate exists means there’s really no work important to do right now, except for encouraging people to use rustc-test instead of the unstable built-in version. In other words, the most important-looking feature in the list isn’t really urgent, considering there’s a simple workaround.
Also keep in mind that people can only use feature flags for features that are already at least partially implemented. There’s no feature flag for #[repr(align)] or for guaranteed-constant-time integer operations, so those features aren’t counted at all. But there are really important features that haven’t even been started yet, which are (IMO) much more important than any of the ones listed.
