It makes you wonder if some of them preceded the whole CR/LF convention.

If I understand correctly, with a true mechanical teletype CR only returns the print head to the start of the line, and LF only advances the paper by one line. If you want to move your cursor to the start of the first line you have to send both, but there's no reason for the teletype to care about their order.

That's almost correct. The order matters to an extent inasmuch as for the older paper terminals one had to delay after sending a CR in order to let the print head actually travel. So it wasn't LF+CR, but actually LF+CR+delay. In the other order it would have had to be CR+delay+LF.

MUDs didn't precede the CR+LF convention, because that convention (if memory serves) pre-dates the Internet itself by a few years. However, it wasn't the case that CR and LF separately had the individual functions that they commonly had a decade or so later. Sometimes, for example, LF on its own was newline, or CR had to be simulated with lots of BSes.

The thing about TELNET is that in 1983 it explicitly specified an abstract Network Virtual Terminal and was definite about what newlines should be for it. See RFC 854. Anything TELNET-based was supposed to operate to that abstraction, not take advantage of the fact that sometimes LF+CR worked on real terminals. An NVT wasn't a real terminal. All of the delays and what the characters really did was supposed to be hidden by the abstraction.

Interesting trivia.

After all, if you're not controlling a mechanical print head, then LF+CR vs CR+LF should always land you immediately in same place anyways because you're just moving the pointer around a virtual grid.

So it makes sense to get it wrong in 1998 since you're post-teleprinter while also in the early days of the convention becoming crystalized.

Unfortunately many older mud servers (diku? Rom?) started with the wrong \\n\\r and codebases spawned from them just continued. Very few send the proper \\r\\n

So yet another of many places where one just has to know that the RFC does not match the real world. An interesting test case for my state machine. But I can see the dragon in the proper colours, now.

Another minor thing you might run into is that servers don't reliably send DONT vs WONT and DO vs WILL when negotiating.

A server (or client) should send `IAC WILL <option>` to announce that it has a capability, and the other party will confirm/reject with DO or DONT.

But some servers will send `IAC DO <option>` even though they are announcing a capability (like server-to-client compression).

Telnet is fun and I like how simple it is. Kinda sad it's basically dead except for what feels like servers that nobody remembered to unplug.