TERM environment variable seen by the GNU Readline library in the Bourne Again shell must denote the correct record in the terminfo database that matches what the terminal at the end of your serial connection actually is.
If you have a switchable terminal type in a terminal emulator at the end of your serial connection, the
TERM variable must switch to match whatever the current setting is.
Traditionally a local real terminal remains physically connected to the same serial line, and the system administrator makes a one-off configuration change so that the
getty program is invoked with the right terminal type. In these days of PCs running emulator programs connected to their serial devices, pretending to be real terminals, one must either keep the emulator configured the same or reconfigure the host system whenever the emulator program is changed.
Currently there is a mismatch, and the control sequence(s) that the GNU Readline library emits to move the cursor backwards, that it has read from the
TERM-denoted record in the terminfo database, do not match the control sequence(s) that your terminal or terminal emulator actually recognizes to move the cursor backwards.
(Deleting to the left when at the end of the line being input is enacted by Readline moving the cursor backwards, printing a space, and moving the cursor backwards again. Observe that Readline always uses the
cub capability, never the
cub1 capability. No terminal uses the
␈ character in its
cub capability. So how your terminal responds to
␈ is a red herring. It is how it responds to the actual control sequence in the
cub capability that is important.)
The line discipline special characters listed by
stty are a red herring for two reasons. They are input processing unrelated to the output control sequences used by the GNU Readline library. And GNU Readline puts the terminal into non-canonical input mode anyway when editing a command line is actually happening.