That would work, if LED modes would stack - you could just override the former stuff. But they don’t, and only one can be active. So if we want NumLock to be just a LEDMode, we need to activate ourselves when numlock turns on, and deactivate when done. This is what the old code did, and it wasn’t reliable. I think it could be made more reliable, but then we’d just shift the magic elsewhere, and wouldn’t reduce it. The current solution is at least - in my opinion, anyway - a bit more explicit magic.
If it’s not a LED mode… well, then we have the current situation. We could simplify it, if we hardcoded the NumLock key position, or made it configurable instead of auto-detected. That would allow us to get rid of the macro stuff, perhaps…
Hmm… now that I’m thinking this through… the reason we use a macro is to be able to get the location of the numlock key, and the macro is what is most confusing. But we could also use an event loop hook, and catch numlock there. The downside of that is that it won’t work if any other plugin catches numlock before us (unlikely), and will only highlight one numlock key (having two is even more unlikely, so this is a reasonable compromise).
I’ll prep a patch =)