Keep in mind that I'm not proposing that we retroactively change our approach to managing any currently provisional APIs that were proposed and implemented under the current version of PEP 411.

Instead I'm merely suggesting that the policy for any *future* provisional APIs be amended to require a runtime feature flag and FutureWarning by default, with the possible disposition of such proposals then being:

1. Rejected (as with any proposal)
2. Accepted with the feature flag and runtime warning in place
3. The proposal is reformulated to include both non-provisional and provisional parts, with the feature flag and warning applying only to use of the latter elements
4. The proposal is reformulated to offer an entirely non-provisional public API without a feature flag or warning (perhaps with a private "_machinery" or "_internals" submodule to better enable third party tinkering and experimentation)
5. The submitter of the proposal successfully makes the case that their proposal is simultaneously stable enough that it doesn't need a feature flag or runtime warning and *un*stable enough that it shouldn't be expected to offer the standard library's usual backwards compatibility guarantees

I personally think the final option will be tricky enough to justify that most folks won't even bother trying, and will instead opt for one side or the other (i.e. the feature-flag-and-warning, or a non-provisional API)

However, it's an option I'd consider reasonable to retain in recognition of the fact that it's been used without problems in the past (e.g. it's plausible that pathlib could credibly have made that case, since the provisional status wasn't due to potential API stability within pathlib itself, it was due to doubts about how well it would be able to integrate with other parts of the standard library. It went unprovisional once the introduction of the filesystem path protocol allowed those integration concerns to be fully resolved).