M1 machines expose serial over Type C, so of course if you cross-connect two M1s they can talk to each other over serial. Conveniently, one of the pin pair options you can select is SBU1/2, which are cross-connected on standard cables, like a null modem serial cable, so you end up with TX connected to RX in both directions and it just works.
This is not a standard Type C feature, so unless another machine happens to also implement a 1.2V serial port compatible with Apple's version and pinout completely by chance, it won't work.
It only works on a specific port on Apple devices (the same one used for DFU, which has the fun debug features like this one), not on all the others.
Sure; Linux already has a driver for a variant of the USB-C chips in these Macs, so normal functionality should work with minimal changes. I don't know if the driver exposes the low-level command protocol to userspace off the top of my head (since we need that to send vendor-specific commands), but if it doesn't, we can probably get away with just using raw I²C access to the chip directly, via i2c-dev. Alternatively, we could add an interface, e.g. a debugfs entry for the Type-C driver that exposes raw commands.
Not sure what approach we'll end up with, but there are certainly multiple ways of doing this under Linux.
This is not a standard Type C feature, so unless another machine happens to also implement a 1.2V serial port compatible with Apple's version and pinout completely by chance, it won't work.
It only works on a specific port on Apple devices (the same one used for DFU, which has the fun debug features like this one), not on all the others.