If this happens, would the core team also consider adding an unstableLanguageFeatures entry to package manifests, where packages could declare their use of non-source-stable features such as _modify, @inline(__always), @_specialize, etc?
I mentioned this before, but we have a serious problem with these features being used in popular first-party and third-party source packages, to the point where they already are de-facto language features and dialects.
It would be nice to introduce some discipline over this stuff. Next month it will be 7 years since Swift was first announced; you shouldn't need unstable language features to write a good Deque, and we shouldn't keep this technical debt around forever.
In the future, I think it would be better to move all unstable features to an opt-in system, in the same way we're describing here. Packages should be built with fallbacks (or just omit API which requires unstable feature), and downstream clients should explicitly consent to enabling APIs built on unstable features through a special package build flag.