Sure, I should clarify.
Regarding "not working" : I was unable to get a status from this handler. But since I posted that reply, I have come across why that is.
Currently on 1.0.1 to 1.2.1, my issue is not with detecting when an OTA update has started, which is what this handler does, but with knowing when to check so that I can hang around longer to let the update process play out. This is particularly important on the ever increasing devices that spend most of their time asleep and are purposefully programmed to wake, connect, and sleep as quickly as possible to save battery. Staying connected for "10 seconds or so" with fingers crossed just isn't a good solution.
In my experience, a handler can be set up to detect when an update is started so that you can keep the device connected/on long enough for the update process to do it's thing. That's not a problem. The problem is that there is no apparent documented "step" or "time" when this happens aside from the "give it 10 seconds or so" posts I've seen in the community forums. In my experience it can happen after 3 seconds and sometimes takes 20+. So if your code runs through, the device connects, publishes, etc before your handler can see that there is an update coming through, it either doesn't happen or fails spectacularly. This is particularly troublesome when you have SYSTEM_THREAD(ENABLED) because you are likely to send your device to sleep during an update.
Two big selling points for the Electron/Boron are remote placement (ie. battery/solar installations) and OTA firmware update deployments. So I am hopeful that there is an elegant solution that I am overlooking.
Here is another thread with some logs and some better descriptions of what is happening.