There's a small risk of CPUs and I/O pins getting fried if GND levels aren't equalized first and instead that equalizing force would go through those pins. One could argue that it's hardware designer's responsibility to save users from such things, but then again, using a better connector than TRS can be one of them.

Thing is, for a serial TTL connector to become ubiquitous, it needs to cover at least something like 99% of scenarios. Or maybe 95%. 3.5mm TRS ain't that, and thus just increases general diversity in connectors.

In my experience noise on hot-plugging the serial adapter is a complete nonissue. I'm sure it matters for you, sometimes. But for this kind of embedded work, I'd say it's important far, far less than 1% of the time.

In my experience with... it's maybe 20? ... embedded boards, junk during boot breaks the boot flow for about half of them. And attaching quickly after target powerup is very often the crux of the exercise, to get to the bootloader fast enough before it moves on, but also you don't have the shifters (or Vref pin) in place to be able to attach beforehand...

Since I once had the case where junk on the line (from a wiggly connection) caused Magic Sysrq requests I'm fully on your side. No junk tolerated for potential hot plug connections.

What byte sequence on a Tx/Rx/Gnd serial line can trigger Sysrq key sequences?

It's not a byte sequence, it's a BREAK == pulling the line low for longer than a byte, i.e. invalid serial framing on the stop bit.

I'm aware of serial breaks, but this is the first I've heard of them being interpreted as SysRq by Linux. That could be handy. Thanks for the tip.

I assume the possibility of spurious Rx state is why FTDI chose to wire Rx to the tip pin of the female TRS connector: It's the last pin to make contact with anything when plugging in, and therefore least likely to be bridged to ground. I suppose the mechanical design of any particular jack would determine whether it's possible at all.