This has absolutely nothing to do with the speed of MIDI. (except that there will be about twice as many MTC messages over the wire)
MTC byte 3, 000fffff: Frame (0–29, or less at lower frame rates)
THUS MTC CAN ONLY SELECT FRAME 0 to 29, NOT BEYOND THAT.
MTC can only address/select these frames
0rrhhhhh: Rate (0–3) and hour (0–23).
rr = 00: 24 frames/s
rr = 01: 25 frames/s
rr = 10: 29.97 frames/s (SMPTE drop-frame timecode)
rr = 11: 30 frames/s
The unused bits in minute and seconds could be used to extend the frame rate bits for "HFR" because the unused bits 6 and 7 in frame# will need to be used for the selected frame (127 max)
One bit could mean to double the frame rate
. That is to 48, 50 and 60 and using the seconds bit to go to maximum of 120fps. (The hobbit was shot in 48fps and many MP4 files are in 50fps, and some really high end media goes up to 120fps)
The request for change is thus as follows:
HFR (High Frame rate) support
minute bit 6 - seconds bit 6
0 0 = standard
0 1 = 2x fps (48, 50, 60)
1 0 = 4x fps (96, 100, 120)
1 1 = Not usable because frame maximum is 127
The use case is that software and hardware with MTC can control the playback of video without first having to down convert the video to lower fps rates.
Sure all applications that send and receive MTC will need to be updated. But it's 2017, it's time.
The MMC Locate command will also have to be updated and it has unused bits as well in the frame byte