I think this ought to be a new PEP which supersedes PEP 411. I think it should simply *offer* the option of using a feature flag rather than prescribing it. It could also explain that feature flags could cover an entire module or only the unstable parts. I would be happy to accept something like that.

I am still unclear as to how you are proposing to implement the "feature flag". Making this an attribute of `__main__` doesn't feel right (I've seen programs with different main entry point). However I do think it could be global state, similar to what `warnings` does (maybe it should just be a warning).

I don't like the parallel with `__future__` imports because those are for *stable* APIs that use backwards incompatible syntax (typically a new keyword).

Thinking back on my experiences with asyncio and typing, I have a feeling that the provisional status was *mostly* used to introduce *new* APIs at bugfix releases. We were in general pretty careful with changes to the documented APIs, with some exceptions for where the design was broken, and we sometimes pushed backwards incompatibilities to feature releases (which get more vetting by users than bugfix releases). But in both cases the API surface was sufficiently large that we simply didn't know in which areas details would have to change in the future, and we didn't want to be stuck with backwards compatibility hacks long-term. (The worst thing is when the perfect name for an API is found to require an incompatible signature change -- if you solve it by using a different the API will forever look ugly or confusing or weird.)

I know there have been times for both asyncio and typing where we wished they weren't in the stdlib at all -- mostly because we had users stuck with a CPython version (e.g. 3.5.1) that was missing an important addition to the API. But all in all I think that for both libraries the advantages have well outweighed the disadvantages. And a required warning on import would have really bothered me.