I've looked through the Universal MIDI Packet and MIDI 2.0 protocol specification (M2-104-UM-1.0), and some issues came on my mind:
1. In Control Change message, the CC number ('index') field takes a different place comparing to Registered (RPN) and Assignable (NRPN) Controllers. For the CC message, the byte order is 'index reserved', while for RPN/NRPN messages it's 'bank index'.
Wouldn't the byte order of 'reserved index' allow CC message to fit better into the controller pattern, so that future revisions of the format could add controller banks if needed?
2. I understand that backward compatibility was given very high priority during development of MIDI 2.0, however the updated Control Change messages have essentially the same format and function as Registered (and Assignable) Controllers.
Would it make sense to just translate current Control Changes #0-127 into some reserved bank of Registered Controllers in a future revision of the message format?
3. It would be helpful to include a list of supported Control Changes in the spec, similarily to the list of Per-Note Controllers, detailing their behaviour and translations to MIDI 1.0.
Specifically, LSB versions (CC #32-61 and #88) are not really needed in the MIDI 2.0 protocol anymore, so these numbers should be reserved. Also these 14-bit MSB/LSB combinations could be mapped to new 32-bit Control Changes (and vice versa).
The current spec only details processing and translation rules for Data Entry controllers #6/38, #98/99 and #100/191, and Bank Select controllers #0/32.
I understand that very few MIDI devices ever used these hi-res controllers, but MIDI 2.0 Protocol devices could probably support them in MIDI 1.0 mode, especially when connected to the computer over high-speed UMP-compatible transports, so that older MIDI 1.0 software would still be able to take advantage of high resolution in MIDI 2.0 devices.
I believe such forward compatibility could be essential for broader adoption of MIDI 2.0.