That sounds like a really great design, and very efficient because the messages could be packed into a uint32 buffer for queuing, no structs, pointers, or linked lists required. In your ideal implementation, would the MidiInHandler signature remain the same to avoid breakage of existing object code? I can see how you could just unpack the 32 bit message into existing parameters, but I don't see how you'd communicate the code index number, i.e. that a message is a sysex continuation for example. I guess another way to do it in a non-breaking way would be to translate supported events for legacy code, and also make a new message buffer available to k-rate code.
Let me know if there's anything I can do to help improve MIDI support. I would really love to add support for hubs, but I have no idea how complex that would be.
P.S. I will point out that my implementation has an arbitrary limit on message length. The 16 bytes is just a constant, and since there isn't currently a queue that buffer is cheap because it only needs to be allocated once. As you say, queuing would make that a huge hassle, which is probably why JACK still has no support for sysex.