Just thinking aloud here but if the Nano grabbed a buffer and then post processed it to look for the baud rate then there is a danger that at any resolution high enough to give good baud rate calculation sensitivity, the sample may be too small to be sure that you’d see a single bit by itself.
[You could never be totally sure anyway of course. Pathological example I know, but a packed stream of 0xF0 chars sent at 48Kbaud is indistinguishable from a packed stream of 0x55 chars at 9600 baud.]
It might be better to only check “normal” baud rates such as whole number divisors of 115200 and do several sweeps.
With the extra code space gcc makes possible, someone enthusiastic could write a nice new mode that automagically monitors the line, decodes not just baud rate but parity and stop bits and displays a comms dump in ASCII and HEX.
Dual trace would be nice for logging RS232 but even a single trace would be fine for RS485 and in practice RS232 would be fine 99% of the time if you used two diodes and a resistor to ground. The number of implementations of RS232 where characters are simultaneously travelling both directions at once is very low.
Come to think of it, for bidirectional RS232 you could build the cable with one signal diode and one red LED in one direction and one signal diode and one blue LED in the other (and of course a resistor to ground). That way, there would be a voltage difference between the two TX drivers and the Nano could tell which direction the data came from. [PLUS there’d be some pretty lights when data arrived!]
That would be pretty cool, but I think we’d be 15 years too late for the market.