🚀 go-pugleaf

>> If so, it downloads
>> escape sequences that do all sorts of magic, in particular they
>> remap CTRL-S to transmit ^].  Then, I fix the
>> keyboard-translate-table (my .emacs asks for confirmation) so that
>> ^] will be seen by the rest of Emacs as ^S.  In this way, I don't
>> have to change any keybindings (whether keymaps or not) nor I have
>> to reprogram myself to type strange things in different terminals.
>> The cost is the loss of ^] (big deal) and the need to confirm things
>> to my .login and my .emacs.

This works fine if the number of characters to avoid is small.
Ultimately, however, your character set shrinks so that some control
key you are fond of using has to become unavailable.

Robert Wells' suggestion to use multi-character substitutions would
solve this, but for the purposes of isearch and friends, you would
want the inversion to happen through the keyboard translate table,
which currently is just a one-for-one character substitution.  Has
anyone tried to make this a general keymap (I know there's a
performance hit here probably)?

Really you want the translation to happen in Unix's terminal driver,
of course.  Here we are really talking about a protocol between the
two ends of the terminal "line" (including port selectors, "clever"
modems and whatever).  The proper place for the support of this is at
the process serving that line.  So this suggests the need for a better
"line discipline" variant that supports the keyboard remapping.  With
this, emacs need never know.

/jr