The MIDI 1.0 spec only allows 7 bits for most all command and data bytes. Use of the high-order bit is restricted to control bytes that denote the beginning, end or continuation of long MIDI records.

So what is the precision of CC #10 (0x0A) the Pan command? The data value is one byte that does NOT use the high-order bit so is defined to be a value from 0-127. The 'Used As' column says 'MSB'

That does NOT mean the precision of Panning is limited to 0-127. A check of the MIDI spec shows that CC #42 (0x2A) is defined as 'LSB for Control 10(Pan)' which also has a data value of one byte, not using the high-order bit, with a value from 0-127. This 'Used As' column says 'LSB'.

Put those two together and you have a potential 14 bits of precision available.

Do manufacturers use both bytes and get 14 bit precision? That is totally up to each manufacturer.

Do manufacturers use only ONE byte and get 7 bit precision? That is up to each manufacturer.

For 7 bit precision which byte is a value from 0-127 stored in? That is also up to each manufacturer but the majority of manufacturers, if not all, use CC #10 (labeled MSB) and don't use CC#42 (LSB) at all.   

The MSB/LSB, when used in a controller context, are often referred to as 'coarse' and 'fine' 

MIDI 2.0 allows 32-bit resolution for controllers and even 16-bit resolution for NOTE-ON velocity. The internal format for this data is true binary and there is no restriction on using high-order bits of bytes.

So how do you correlate 32-bit and 16-bit MIDI two data with the 7 bit (or 2 byte 14 bit) limitation of MIDI 1.0?

That is the 'elephant in the room' the manufacturers have to deal with. And we can likely expect some of them to deal with the issue differently.

That is where the 'all important' CI (capability inquiry) of MIDI 2.0 comes into play.