missed one odd encoding=

What you are suggesting is I didn't need any of thisget_encoding() logic - tangent I went on. In the absence of the-X utf8, I just needed to selectively remove all the, encoding="utf-8" options where I needed the system encoding to dominate.

Since merged - do I push an update or need a new PR?

I just needed to selectively remove all the , encoding="utf-8" options where I needed the system encoding to dominate.

nothing is written to file, so no need for encoding= to possibly confuse future reader(s)
python won't re-encode stuff, this is just the thing for read / write through text io wrapper

in absence of -Xutf-8, text io selects something default aka depends on version
https://github.com/python/cpython/blob/cbd192b6ff137aec25913cc80b2bf7bf1ef3755b/Modules/_io/textio.c#L1102-L1141 (our bundled version)
https://github.com/python/cpython/blob/ddb65c47b1066fec8ce7a674ebb88b167f417d84/Modules/_io/textio.c#L1126-L1132 (3.11 on any recent installation)

utf-8 output is ok, reading cli / writing stuff for external tools should have system encoding

nothing is written to file, so no need for encoding= to possibly confuse future reader(s)

Just for clarification when creatingbuild.opt, we are readingutf-8 from dot-h files and writing with system encoding tobuild.opt otherwise I can get a file not found for a-include ... if the file path contains diacritics.

also nit:

diacritics

any time we have characters from codepage different from ansii e.g.C:\Users\Максім in cp1251
just my guess that GCC probably does not use win32_wfopen and widechar, so we have to use exact codepage bytes for filepath representation so system exec (that also does not encode / decode anything in args) for GCC gets proper paths

path and text have different code sections dealing with them, just to denote the difference

(I am gonna go readPython PEP 529,https://vstinner.github.io/python36-utf8-windows.html series and cpythonunicodeobject.c)