It's actually called "PYTHONLEGACYWINDOWSSTDIO" in Python/pylifecycle.c, which is also what PEP 528 says it should be, so this is a docs issue. You're correct that PYTHONIOENCODING is overridden by detection of a real console, however, PYTHONIOENCODING doesn't currently set a flag anywhere, and the (required for compatibility) defaults on Windows would make it look like it's always been set to something else. In my opinion, you should set PYTHONLEGACYWINDOWSSTDIO to indicate that even though we know the incoming encoding (Unicode from an interactive console), you don't care and you want to override it with a default value. Then use PYTHONIOENCODING to set that default value. This is most consistent with the existing use of PYTHONIOENCODING (it's the default unless you know exactly which encoding you are getting).
I prefer the name PYTHONLEGACYWINDOWSIOENCODING for symmetry with both PYTHONIOENCODING and PYTHONLEGACYWINDOWSFSENCODING, but I suppose you changed it to make it more visually distinguished from the latter. I discovered this issue due to the modified behavior of PYTHONIOENCODING. It's not really a disruptive change, but it looks wrong based solely on the --help text description of PYTHONIOENCODING. An alternative would be to set Py_LegacyWindowsStdioFlag in _Py_InitializeEx_Private either when PYTHONLEGACYWINDOWSSTDIO is set or when PYTHONIOENCODING isn't a case-insensitive match for "utf-8" with an optional :errors spec. That way people get exactly what they asked for, even if it's mojibake nonsense given the console's current input and output codepages.
Sure, but you're proposing a change to a correctly documented (apart from the variable name) and released behavior. It can't be changed in 3.6, and I don't see a compelling reason to have different behavior in 3.7.
