Silicon isn't the bottleneck here, you could probably rig it up on existing chips. I can think of a way to do it with a stereo codec and surround codec with a mux in there, it wouldn't be super cheap but for pro gear, who cares.

The big blocker is the drivers and compatibility with existing software. Audio people do not like tooling changes, and what I'm talking about is a rather fundamental change to very low level components in MacOS and Windows, the former of which is more important and already does things very well and would take a massive engineering effort with little ROI (CoreAudio is a marvel).

On Linux you could do some impressive shit, and how I'd like to do it is via a hypervisor that hogs a core for audio processing and provides an API back to the system for communication. I know there has been some work to do that already, but incorporating hardware changes to support it would be fairly high cost with fairly low ROI.

This kind of thing could be done, sure, but the money in pro audio and speed of adoption are non-ideal. You're talking 3-5 years dev cycle to get a prototype shipped and in stores, ask users to give up a lot of hardware, and for a subtle change in what they hear.

This would be a project for my free time after an extremely lucrative exit event from my current venture, and I'd have to add it to the list of pro audio paradigm shifts I'd want to work on.

Given your later explanations of what you actually mean, none of what you're talking about can possibly help.

MIDI is a serial protocol without timestamps. It is not possible for it to have "N notes with the same timestamp" because MIDI messages/events do not have timestamps. There is no notion of any time other than "now" in the MIDI protocol.

In the early 2000's there were MIDI hardware interfaces that did accept a timestamped event stream, and claimed to provide much better timing than those that just "send it out ASAP". These gained zero traction in the industry because nobody could actually tell the difference, and it required h/w-specific code, which nobody likes.

Your "how i'd like to do it" on Linux is impressively wrong in the sense that you do not need a hypervisor and you do not need hardware changes. We already do this on Linux, when desired (e.g. embedded Linux in the mixer consoles on several pro-audio companies).

I've spent 20 years writing pro-audio+MIDI software after "an extremely lucrative exit" from a previous venture. I don't think you understand what the actual pro-audio paradigms are, nor how they could be changed.