Non ASCII compatible encodings (UTF-16, UCS-2; presumably UTF-7 too) should be removed from the list of offered encodings.

Any valid character might easily include a byte in the 0x00 - 0x1F range, which will trigger a special action according to the kernel's line discipline, such as send interrupt to the foreground process, send EOF, newline, wipe out the buffer etc., or just simply being echoed back in a way that's broken in UTF-16.

That is, the behavior is bound to be broken big time, there's nothing you could do to fix this.

The kernel expects the data on the terminal lines to be ASCII compatible.

I'm almost certain the Linux kernel doesn't support UTF-16 here, and I don't think other Unixes do either. (If some does, offering this option should be limited to these architectures.)

See https://unix.stackexchange.com/questions/448745/strange-konsole-character-encoding-behavior/448774 for a related question and my more detailed answer.

I'm not familiar with UTF-7 and cannot tell whether it's usable, but heck, no one uses it anyway.

(This bugreport is basically a copy of https://bugs.kde.org/show_bug.cgi?id=395171.)