Did you ever send me down a rabbit hole on this question! And I cannot guarantee that my answer is correct. But I did my best. And it all adds up.
There's a human interface device definition from the USB body that defined "USB key codes", which are a logical sorting of all possible keyboard keys. However this is an abstraction. Below that is another layer called "USB scan codes", which tend to number the keys by their physical layout on the keyboard. It is this layer that KM uses to detect keys.
From my reading, the lower level (scan codes) can be different for keyboards from different manufacturers. I found a list of Apple scan codes that differ from the scan codes from IBM. I am including two USB organization's USB links below. The first one is the USB HID guide, the second one is its parent link.
The root of the document is here:
https://www.usb.org/hid
Apple's scan code list is findable online, but my source doesn't come from Apple, other than saying it comes from an Apple file called EVENTS.H:
kVK_Return = 0x24,
kVK_Tab = 0x30,
kVK_Space = 0x31,
kVK_Delete = 0x33,
kVK_Escape = 0x35,
kVK_Command = 0x37,
kVK_Shift = 0x38,
kVK_CapsLock = 0x39,
kVK_Option = 0x3A,
kVK_Control = 0x3B,
kVK_RightShift = 0x3C,
kVK_RightOption = 0x3D,
kVK_RightControl = 0x3E,
kVK_Function = 0x3F,
kVK_F17 = 0x40,
kVK_VolumeUp = 0x48,
kVK_VolumeDown = 0x49,
kVK_Mute = 0x4A,
kVK_F18 = 0x4F,
kVK_F19 = 0x50,
kVK_F20 = 0x5A,
kVK_F5 = 0x60,
kVK_F6 = 0x61,
kVK_F7 = 0x62,
kVK_F3 = 0x63,
kVK_F8 = 0x64,
kVK_F9 = 0x65,
kVK_F11 = 0x67,
kVK_F13 = 0x69,
kVK_F16 = 0x6A,
kVK_F14 = 0x6B,
kVK_F10 = 0x6D,
kVK_F12 = 0x6F,
kVK_F15 = 0x71,
kVK_Help = 0x72,
kVK_Home = 0x73,
kVK_PageUp = 0x74,
kVK_ForwardDelete = 0x75,
kVK_F4 = 0x76,
kVK_End = 0x77,
kVK_F2 = 0x78,
kVK_PageDown = 0x79,
kVK_F1 = 0x7A,
kVK_LeftArrow = 0x7B,
kVK_RightArrow = 0x7C,
kVK_DownArrow = 0x7D,
kVK_UpArrow = 0x7E
It may be worth noting that the Eject Key which can be found on Apple's keyboard does not appear in this list, which is probably why KM cannot detect that key. (Although it might be an undocumented key and if Peter tried guessing a few unused values he might uncover it - I see only 5 possible values.) It's also worth noting that in this list F1 is x7A, which converts to 122, which is the number in ccstone's script above. Also note that the unusual key called Fn (sometimes Globe) is in this list, and note that KM can detect it.
There is one thing about this list that I cannot understand. That is, we can see entries for Mute, VolumeUp and VolumeDown, but not for the 7 other Shift+FunctionKey buttons. HOWEVER, I see an empty block of seven values from 41 to 47, and I'll bet that's where they fit. Regardless, I don't see any need for there to be two sets of scan codes for the function keys and the "media keys." I suppose Apple just conflated the idea of a "scan code" with a "key code".
I find it fascinating that when I flip this switch from blue to disabled (as shown below, it's disabled):...
...KM has the odd behaviour of recognizing only F5 and F6, but none of the others from F1 to F12. This is because Apple uses that switch to determine whether the row of function keys returns one set of Scan Codes or another. In either case Apple leaves the scan codes for F5 and F6 alone.
I think it pretty much all makes sense.
I'm well aware that Peter would never attempt to implement undocumented Apple functions like the scan code for the Eject button, but I have a hunch it would work if he tried it, at least until Apple changed the meaning of the undocumented scan codes.