The problem as I see it is around features that are both
- stable enough that it was used and stabilized in the same form,
- useful enough that they were used rather than a stable-compatible shim, and
- old enough that libraries that used them in development are no longer in active development (otherwise they’d just remove the flag)
so this leads me to believe that some sort of “semi-stable” feature flag would be the proper response to this, for features that are likely to fall into the above case.
Note that, importantly,
#![feature] is not a part of the Rust language. It’s a research feature implemented by rustc nightly to opt-in to unstable features not yet added to stable. rustc beta and rustc stable recognize this attribute and give a special error for it, as they know what it likely is (as rustc stable is just rustc nightly with a different config), but this doesn’t make the attribute part of the language.
I honestly don’t know where I stand on this. But whatever choice is made, it should make sense from the perspective of just stable Rust.
There’s also been some mention of removing old feature names from the compiler as a form of cleaning. This would be impossible if stabilized feature names are whitelisted on stable. cc @Centril, haven’t you argued this position before?