So, I feel it’s time for another mild rant about leaky abstractions.
NumLock is a kludge. It is a kludge designed for the first IBM PC so that a directional pad and a numpad could be supported on the same limited keyboard. Its inadequacy was soon evident, so the PC/AT model M and all subsequent IBM compatible PCs have supported keyboards with separate directional and numeric keys.
To its eternal credit, Apple never implemented NumLock. To its eternal shame, Linux did.
Unfortunately, because NumLock was a software feature it had to be kept around for backwards compatibility. And then it became unkillable, to the point where modern compact keyboards that have no hard numpad (laptops, kinesis, Model01…) still have to handle NumLock.
The vast majority of PC-compatible hardware has long supported a default BIOS option “Enable NumLock on boot”, which effectively means that the user can pretend that NumLock does not exist. This appears to me to be the sensible option, and is one that is both widely supported and widely expected. On most laptop keyboards the numpad is accessed by holding down Fn. With NumLock-on-boot, this produces numbers, as it should. NumLock itself is normally hidden so well that it takes a magnifying glass to find it (on my Dell, it is Fn-F5). The only problem comes if you disable it by accident (which is why it is well hidden).
For whatever reason, the Model01 does things differently. Instead of letting the BIOS enable NumLock-on-boot and follow the practice of every other compact keyboard, it overloads the Num key and makes it toggle both the software NumLock and the firmware keypad options. When these remain in sync, nobody notices. When these fall out of sync, we have a nasty abstraction leak that renders the numpad unusable.
What is the advantage in a “smart” numlock key like this? What problem does it solve?