This is excellent, but it would be nice to quantify how much the battery does suffer. Is the node RX only (during programming) or is there a TX part of the protocol? If the default startup simply quiesces everything almost immediately, ie, gets the node in low power listen mode ASAP (as part of boot process), then this could be useable, without any elaborate sequencing scheme.
For the burst protocol it's request / response with every request selecting up to 1024 bytes of data to be sent back from the server. The response is sent in a continuous burst similar to the Listen code. The key to the efficiency of the protocol is that only bust packages that weren't received are requested again, eliminating retransmit latency.
I set the fuses for the 8mhz internal clock with the 8x clock divider set, so I start up at 1Mhz. First thing I do is to put the radio to sleep. Then I wait for the battery to recover. Then I select 1Mhz and send a boot request to the server asking if a new version is available. Based on the voltage drop during that send I select the simple or the burst scheme for the install.
If a new version is available I pull it from the server request by request, pausing after each request until the battery recharges the cap and recovers (effectively I measure vcc, go to sleep for 250ms, measure vcc again and continue this loop until vcc no longer improves). I flash pages as they arrive.
I don't yet have detailed data on the battery impact. Remember this just started to work yesterday - still lots to sort out.