With more bytes in a MIDI2 message it could have been feasible to select a higher controller index than 127 in one messages, but it's not the case. bits 0-7 are reserved.
An UMP device (a synth or controller) could get the data for a control into one message instead of using NRPN and NRPN or using separate MSB/LSB controller messages. it probably would be a solution to allow for more controls to assign to DAW/plugin etc.. controls.
What has been the reasoning for UMP MIDI2 to leave the controller index limited to 7 bits ? For example, it could be done in such as way that if bit 15 is reset, b14-b8 and b7-b0 should be treated as legacy MSB/LSB format. and when the b15 is set it would mean to use other 15 bits as the index. that would provide for a lot more controllers in one message. Now the controller message is limited to a 7 bit index and two messages are needed to select an >7 bits index. The same way as in legacy MIDI.
Or I may have interpreted this incorrectly ? Was the idea to "promote" NTPN/RPN over controller messages and keep the controller just for legacy transactions ?
A large part of the design for UMP was to ensure backwards compatibility, hence keeping with some of the same limitations.
The MIDI 2.0 Protocol (message Type 4 in UMP) now has a single messages for (N)RPNs so that means that we have 16384 potential controls for each space.
IMHO a missed opportunity. NRPN/RPNs are very seldom used in DAWs and other application.
I support the current specification and the overall strategy that the specification implements regarding backward compatibility in CC index. DAWs do not support CC numbers beyond 127 either. NRPN or Assignable Controllers is the appropriate way to support mapping of audio plugin parameters. I do design and implement them as such in my plugin format too.