[usrusr]

It's not latency that GP was bemoaning, it's the sequential nature: two note-on measures cannot arrive at exactly the same time. If it was just constant latency, GP probably wouldn't mind (or criticize that, but it would be a completely different argument). Latency alone can actually be worse with real instruments because electrical signals easily outrun sound. (Nerve conduction velocity however is the worst of all, it's a wonder that we can function at all with that shitty data transmission)

[PaulDavisThe1st]

No serial protocol with "real time" semantics can ever deliver two events at the same time. To do that requires scheduling of events before they are due to occur. MIDI doesn't work that way, and probably never should.

Even in highly time-aware percussionists, sensitivity to timing is way below the timing delays that MIDI causes (e.g. with note smearing in a chord).

[usrusr]

With a defined artificial latency headroom and a message parameter to (partially) override that latency it would be possible. With reasonable low maximum concurrency and a very high bandwidth/message size ratio the required extra latency could stay well within the range of centimeters at speed of sound (a very high bandwidth/message size ratio would certainly also lessen the cost of not taking that feature).

The next roadblock on the way to truly concurrent chords would probably be controller readout. I know nothing about how those are typically implemented, but I strongly suspect sequential readout.

[PaulDavisThe1st]

The existing spread for a typically chord (triad) is already not audible (despite the claims of some people who refuse to double blind test it).

Changing MIDI to have "defined latency" is a fundamental re-engineering of the entire protocol.