So, here's the current state of things, for reference, in case I decide not to address this right away.

Typing characters whose Unicode values are under 256 (u+0100) is possible, because when disp_readev_fn calls EncodeChar() on it with the default encoding, it gets mapped to its latin1 equivalent (same code point), which can then be stored in a string.

Typing most characters beyond that range will result in a mapping to '?',

few characters beyond u+0100 get transcoded as an ISO-2022 sequence (halfwidth kana, for example; or ISO 8859-15); this winds up being a worse case for colon-mode input, though, as the resulting embedded ESC character triggers exit of the colon-mode, and the remaining charset identification characters get spewed to the shell instead. That is, try to type or paste a halfwidth kana character in colon-mode, and instead of getting either the character or a '?', you'll get "(IX\033(B" spewed to the shell (where X is actually some arbitrary other character).  (That's if pastefont is on.)

.

The problem with month names not being transcoded properly is a wholly separate issue, however. The individual bytes of the strings used for status lines and such are expected by PutWinMsg to represent individual characters. That works great for latin1 chars when they're input in colon-mode, but not for bytes that were copied directly to the buffer from strftime, using whatever locale happens to be current.

The result is that individual bytes of UTF-8 chars are treated as individual characters. The russian month resulted in digits because, as that poster expected, the 0x04 bytes are stripped, as they are detected as Ctrl-D characters.

.

So there are multiple problems:

 - Screen needs to be aware of the current encoding when it uses locale-dependant strings, such as the name of the month, and transcode it to the one assumed by PutWinMsg (currently latin1). Perhaps until this problem is resolved, names of days and months should always use the C locale, so sensible data results (otherwise French locales could be made to work, but non-latin ones like Russian could not be).
 - Layers using encoding 0, such as the overlay used for colon-command input, are not capable of handling most Unicode characters. Probably, the input overlay (and perhaps others) should use UTF-8 instead.
 - PutWinMsg is not set up to handle encodings other than latin1. It should use UTF-8 (this requires the above change, plus changes to anything else that needs to know the encoding for "window message" strings (probably screenrc parsing of commands like "caption").

The underlying sources for most of these problems are architectural, and require risky changes, which I probably won't wish to make before 4.1.0 is released (so screen will most likely continue to be broken in its handling of non-ASCII characters, much the same as it always has been).