If you change to "local echo" it would cause problems with programs such as vi which will interpret certain characters (such as hjkl) as special commands and won't actually draw them on the screen.
If you start a remote program that just "eats" your input without updating the terminal (like a password prompt) you won't see the 2nd tcp roundtrip.
You'd have the same behaviour with a serial link, rsh, telnet or anything else.
I think I saw a custom SSH client on hn some months ago that would try to compensate high network latencies by echoing the characters locally while waiting for the remote reply. It would then undo the local echo and use the "authoritative" reply instead.
In a lot of scenarios, the latency is not much of an issue, but on wlan/3g, this very fast become very noticeable. In the few cases since, I've used ssh on wireless, I suddenly find myself noticing how much of an issue the sudden feedback delay might be at some times.
The only obvious downside to Mosh I've seen so far, is that a lot of enterprisy firewalls tend to block UDP traffic.
Perhaps this extra complexity would lead to all sorts of strange bugs though.
I don't think ssh sends that back to the client terminal though, but I must say I'm not really sure how that's handled. On one hand I'd like to know better how unix TTYs work, but on the other I value my sanity so I'm probably not looking back into those just now :).
In that case, I guess this functionality would be implemented similarly to the example you mentioned of stopping the client from sending every keystroke at a password prompt, right? It seems like it would be strange for ssh to send the 'toggle echo' signals to the client, but not the 'toggle canonical mode' signals (which the client could also handle in a useful way).
TIOCPKT_IOCTL(EXTPROC) and TIOCSIG support landed in Linux kernel 2.6.36: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
I had to write an SSH terminal inside a browser, and it was full of "why the heck did they"s followed ten minutes later by "oh, that's why"s.
This will explain it better than I ever could:
They could potentially use this information to know the length of a password, which would make brute-forcing easier. A very hypothetical attack, but fun to think about! Less effective than a $5 wrench, no doubt.
Specifically, the section on "Why not send whole commands" made me wonder who this is targeted at, its pretty basic UNIX stuff to know how an Async ASCII terminal works.
mosh actually does something in between (and thus have display errors sometimes)
UDP _is_ great for "streaming" data, meaning data sent piecewise over a continuous connection (or, at least, emulated connection) because packet loss / reordering is an acceptable loss, since a minor blip is less destructive than pausing the video. In this type of setting, packets that arrive out of order (i.e. a packet that was sent earlier arrives after a packet sent after it has been received) are thrown out and the process keeps on chugging.
BTW: awesome handle - south park, lol :)
The set of Source IP:Source Port:Target IP:Target Port is how most connections are differentiated. All four of those combine to form a unique connection identifier.