NB! ModifyOtherKeys protocol supports two modes.

In mode 1, activated by xterm -xrm '*modifyOtherKeys:1' or \033[>4;1m, only several key combinations are encoded in ModifyOtherKeys mode.

In mode 2, activated by xterm -xrm '*modifyOtherKeys:2' or \033[>4;2m, more combinations are supported, but quick search with Alt+letter stops working for non-Latin letters.

I am defaulting to mode 1 for now in the PR above, but in future we should make an option for user to decide.

UPD: I could not find any public issue tracker of xterm, so I wrote an email to it's author:

Hello, Thomas,

I would like to kindly ask for some improvements to the modifyOtherKeys protocol in xterm. Currently, when mode 2 is enabled, combinations of the Alt key with any letter in a non-Latin keyboard layout do not send any ESC sequences at all. In fact, they don’t send any characters either. I believe this is a bug. At the very least, a sequence of ESC and corresponding unicode char should be sent in this case.

Best regards,
Ivan Sorokin

quick search with Alt+letter stops working for non-Latin letters

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093056

Bug in xterm with Alt+non_Latin_letter could be fixed by adding

        /*
         * For combinations of the Alt key with text-input keys,
         * in the case of a non-English keyboard layout,
         * we will send the Unicode character corresponding
         * to the pressed key.
         */
        int codepoint = keysym2ucs(kd.keysym);
        if ((input_char == -1) && (evt_state & Mod1Mask) && (codepoint > 0x7E)) {
            input_char = codepoint;
        }

just after

      input_char = ((kd.keysym < 256)
        ? (int) kd.keysym
        : ((kd.nbytes == 1)
           ? CharOf(kd.strbuf[0])
           : -1));

in input.c