> It isn't good to have "-X dev" do magical things that can't already be replicated with other options.

While it might be nice to be able to replicate -X dev "manually", I didn't try to implement that. The current implementation of this option is more complex than what I expected, especially for warnings.

> Writing that issue made me realise another quirk with `-X dev` though: as a command line option, it should really take precedence over PYTHONWARNINGS, while remain subordinate to other explicit -W options.

IMHO -X dev should change the default, but let the developer overrides options set by -X dev. For example, -X dev -bb works as expected: raise BytesWarning, and this is a test for that. There is also a test for -X dev -W error: -W error has the priority over -X dev, I did that on purpose.

When I started to implement -X dev, I didn't expect so many corner cases. The problem is that the code reading the "configuration" (command line arguments, environment variables, a few configuration files, etc.) was spreaded around CPython code. You know that very well, since you wrote the PEP 432 :-) Fix the implementation of -X dev was my first motivation to work on the implementation of the PEP 432: bpo-32030.

For PYTHONWARNINGS vs -X dev, I'm not sure. It's rare to use PYTHONWARNINGS. I put PYTHONWARNINGS and -W options at the same level. If someone uses PYTHONWARNINGS, warnings are likely already well understood. Overriding PYTHONWARNINGS with -X dev can be seen as a bug. Sometimes, you cannot set command line options, only environment variable. There is -X dev, but there is also PYTHONDEVMODE=1 ...