I hadn't tried it in v6 in a while. I'd pretty much resigned
myself to # and @. But I see the effect in v6, even without
changing stty and it 'works', but in svr2, if I type lsa and then
hit ^H it backs up a place, but then when I press enter the shell
says something along the lines of - lsa^H: not found.
That's exactly what you expect when ^H is not magic: it is echoed back to /dev/tty like any other normal character, and your emulator does what ^H means per X3.4: it backs up the cursor by 1 column.
But by
adding stty erase ^H, it then 'works' the same as in v6. Seth's
steer regarding setting erase and echoe 'fixed' things, once I
figured out that having DEL doubling as intr wasn't ideal.
A nice hack in stty (though I am not sure how far back it goes): you can enter ^H either with an actual backspace character or with the two-character sequence ^ followed by h or H. The second form has the advantage that it can be typed correctly no matter how badly you have screwed up your control characters.
Oh, the mysteries of terminal interaction.
Not _that_ mysterious. Grab ECMA standard 48 (technically equivalent to ANSI X3.64) at <
https://www.ecma-international.org/wp-content/uploads/ECMA-48_5th_edition_june_1991.pdf> and you'll know all about how terminal emulators behave. It isn't hard to read, once you have learned to read "00/13" as hex 0D, which everyone knows right off is CR. (If not, <
asciitable.com> is your friend.) The reason for this bizarre row/column notation is so that escape sequences are always binary no matter the encoding: the sequence that introduces multi-character control sequences is usually spoken of as "ESC [", but technically it has to be sent to a conforming terminal as "\x1B\x45" even if the encoding is EBCDIC, where "ESC [" would be "\x27\xBA" (at least in the US/Canada flavor of EBCDIC).
Bugs are another matter, of course.