Also seems to be *nix specific. On Windows, that test invocation, with -m 'test_write', runs no tests. Omitting that runs 741 tests, with no warning after executing set LC_ALL=C.

On Windows you should not use single quotes (actually they are not needed here on Posix too, it is a remnant of other filters).

Duh. With double quotes or none, test_write runs and passes without warning. But the debug build says it is running with "locale=cp1252". It seems that the LC_ALL setting is ignored on Windows.

AsObj() has 3 code paths to encode a Python str object to Tcl/Tk:

#if USE_TCL_UNICODE
        if (sizeof(Tcl_UniChar) == 2)
            encoded = _PyUnicode_EncodeUTF16(value,
                    "surrogatepass", NATIVE_BYTEORDER);
        else if (sizeof(Tcl_UniChar) == 4)
            encoded = _PyUnicode_EncodeUTF32(value,
                    "surrogatepass", NATIVE_BYTEORDER);
        else
            Py_UNREACHABLE();
#else
        encoded = _PyUnicode_AsUTF8String(value, "surrogateescape");
#endif

From Python, I don't see any way to detect how to know which code path is taken: USE_TCL_UNICODE and sizeof(Tcl_UniChar) are not exposed in the Python API. Not even logged by test.pythoninfo. Well, USE_TCL_UNICODE is not hard to guess :-)

#ifdef MS_WINDOWS
#define USE_TCL_UNICODE 1
#else
#define USE_TCL_UNICODE 0
#endif

Maybe sizeof(Tcl_UniChar) should be exposed in the _tkinter extension.

TESTFN is '@test_452347_tmpæ' string in my case. This string can be encoded to UTF-8:

>>> '@test_452347_tmpæ'.encode('utf8')
b'@test_452347_tmp\xc3\xa6'

I checked that FromObj(AsObj()) gives back the same string.

No, the problem is that the Tcl/Tk calls ('::img::test', 'write', '@test_452819_tmpæ') doesn't handle non-ASCII characters and escapes them using surrogateescape for an unknown reason :-(

For now, honestly, I would suggest to simply use an ASCII filename.

No, it has no relation to how Tkinter convert strings between Python and Tcl.

Tcl uses Latin1 encoding for the C locale, while Python uses UTF-8. Tcl command

open \u00e6 w

creates file with name consisting of one byte 0xe6 in the C locale.

It would be better to document this, but there is currently no place in the documentation where it would be appropriate.

And we need to add a workaround in the test.

It would be better to document this, but there is currently no place in the documentation where it would be appropriate.

Would it be possible to update the Python tkinter module to use the expected encoding, rather than documentation an issue?

Possible -- maybe, but with a great difficulty. You need to add a list of Tcl command that takes or returns a path, a list of options that correspond to a path, a list of variables that store paths, and on every conversion between Python and Tcl look up in these tables and re-code string from UTF-8 to Latin1 and back. It may be even more difficult if there are other conditions of if the required information is not available at the point of conversion.

Can we configure Tcl to use another encoding than Latin1?

Setting locale to C.UTF-8 helps.

But this is application-level change.

Thanks for the fix.