ISO 2022 in terminals

[Keith Winstein]

Hello Markus and Thomas,

I'm working on a UTF-8 replacement for screen-over-SSH, and was excited by 
Markus's paragraph at http://www.cl.cam.ac.uk/~mgk25/unicode.html#term:

   With UTF-8, it is not possible that your terminal remains switched to
   strange graphics-character mode after you accidentally dumped a binary
   file to it. This makes a terminal in UTF-8 mode much more robust than with
   ISO 2022 and it is therefore useful to have a way of locking a terminal
   into UTF-8 mode such that it cannot accidentally go back to the ISO
   2022 world.

Do you know what happened to this admirable idea? It seems like the major 
terminal authors have mostly relented, and now interpret ISO 2022 shift 
sequences again, even in a UTF-8 locale or UTF-8 mode.

I can't figure out how to get xterm, gnome-terminal or GNU screen to NOT 
interpret these shift sequences. By default, it looks again possible to 
have these terminals get stuck in a strange graphics-character mode (and I 
can't even figure out how to "lock" them otherwise) -- what am I missing?

It seems like the ncurses folks believe that ISO 2022 is the preferred way 
to go -- ncurses continues to send ISO 2022 shift sequences for its ACS 
characters except in some special cases.

ncurses has special-cased the terminal types of "linux" and "screen" (by 
the string in the TERM environment variable) and sends UTF-8 graphic 
characters to those terminals ("linux" always, "screen" sometimes). But it 
calls those terminals "broken" and sends ISO 2022 by default to everybody 
else.

Is there any progress on finishing the move to UTF-8 so we can turn off 
the interpretation fo ISO 2022 sequences, or did it turn out this was a 
bad idea?

Would appreciate any insight -- I am tempted just to have my program set 
its TERM to "linux" (which will be carried over an SSH session) so that 
ncurses programs send it UTF-8 instead of ISO 2022 and I can ignore the 
shift sequences!

Best regards, and thank you,
Keith