Midi can plug-and-play so easily because there is no handshaking. Every midi capable device has already agreed upon the 31,250 serial baudrate and 8-bit data + 1 stopbit format and the commands.
The only occasional problem I'll experience with midi is if I unplug before sending a note-off for a note, then that note might forever be stuck on.
The problem is that there is no such thing as a disconnect signal, so a device can't know a cable has been pulled or something in between has been powered off; if it happens then the device is left hanging with a note on, and one must find a way to send the relevant note off or the all notes off message when communication is restored.
Adding such controls (aside the simple reading of the current loop value that doesn't solve all problems) would require one more layer which would translate in more complexity and more latency.
If I had to implement such things on top of an improved protocol, I would likely also ditch the serial link, ignore completely USB, and jump straight to Ethernet, which is damn fast, near realtime, supported pretty much everywhere (Ethernet switches would essentially work as MIDI Thru boxes) and free of royalties. Devices in the same local network wouldn't even need the transport and above layers to work, so latencies would be extremely low, but adding more IP stack layers would allow to remote things easily.
> jump straight to Ethernet, which is damn fast, near realtime
And could optionally use ptp (precision time protocol) Ethernet interface so that the local network clocks are synced to sub-microsecond precision, and so can put timestamps on the midi messages so they can be properly sequenced.
And for increases reliability, incorporate with AVB which uses stream reservation to ensure priority packets can get sent.
Btw I think the hard part is probably not he implementation of Ethernet, but getting hardware vendors on board. Midi 2.0 needed a lot of companies to be on board for the change.
Perhaps if you make adapters and translate devices to help folks transition.
There already are adapters around and software/libraries to build applications to tunnel MIDI over IP, but the hard part IMO is to define a standard so that different products can talk together. Small Ethernet capable microcontrollers are cheap, so once a standard is defined it would be easier to implement it on devices.
The midi out port provides a small current (a few mA) that is used only to drive the photocoupler at the receiver side (per MIDI specifications, transmitter and receiver have to be electrically insulated). It doesn't and can't supply anything else, although in the past some manufacturers produced little out-of-standard devices that took their supply from the MIDI signal, but they were mostly marketing gimmicks.
Moreover, MIDI is a digital signal which doesn't carry any status about the media it travels through; I mean, 10 seconds of nobody playing would appear identical to 10 seconds after a pulled cable.
The only occasional problem I'll experience with midi is if I unplug before sending a note-off for a note, then that note might forever be stuck on.