I'm not happy with the direction this is taking. I would prefer an approach that *first* implements the minimal thing (an internal flag, set by an environment variable, to disable the peephole optimizer) and *then* perhaps revisits the greater UI for specifying optimization levels and the consequences this has for pyc/pyo files.
I would also like to remind people the reason why there are separate pyc and pyo files: they are separate to support precompilation of the standard library and installed 3rd party packages for different optimization levels.
While it may be okay for a developer that their pyc files all get invalidated when they change the optimization level, the stdlib and site-packages may require root access to write, so if your optimization level means you have to ignore the precompiled stdlib or site packages, that would be a major drag on your startup time (and memory usage will also spike at import time, since the AST is rather large).
Looking at my own (frequent) use of coverage.py, I would be totally fine if disabling peephole optimization only affected my app's code, and kept using the precompiled stdlib. (How exactly this would work is left as an exercise for the reader.)