Since I was already writing the same values to the chip registers that Asus was, then I had to assume something else was at play, so I had to start the investigation from the beginning and attack it from a different angle.
It turns out that on the RT-AC68U, Asus doesn't let the hardware/wireless driver handle the flashing of the 5 GHz LED. Instead, they have the watchdog turning the LED off and on through software every few milliseconds as needed to generate the fast blinking on activity.
To achieve this, the watchdog calls the led_control() function. In the stock firmware, that function merely writes to the hardware to turn the LED off or on. In my FW, since Stealth Mode also uses that same function, I was also writing to the chip the behaviour the built-in LED flashing should use (off, or on-blinking-on-activity).
So basically, each time the software-based blinking was trying to turn the LED off or on for a few ms, the router was also disabling/enabling the hardware-based blinking function. So sometimes due to timing issues, the LED would stay on or stay off longer than expected, as the hardware was trying to do its own blinking on top of the software-based blinking done by Asus.
To resolve the issue, I had first to modify the way led_control() worked so it would no longer by default manipulate the led behaviour at the hardware level, and I had to add a special case so both Stealth Mode and user-created scripts would still work properly (disabling/enabling the LED behaviour).
No need to say that tracking down this kind of issue isn't a 5 minutes thing...
