Indeed, I was surpised when it worked. Rather, I was surprised when I hooked up the ammeter and saw that it really WAS dropping to a less-hungry power situation (I figured it was just staying full power and not really dropping, but not throwing errors, either).
I think I tried the other LPMs and noticed a different current reduction at each, so I just went as deep as I could with still having the thing play (and wake up) properly. I know I am out of my league when dumb luck lets me get something built better than I had planned. *smile* Maybe it will "break" with a future Eneriga update or something, and that will provide more clues as to how this is working now!
Thanks for the info about ...exit(). If anything DOES draw me further into MCU programming, it will be interrupts. Though many books and docs talk about how the interrupt paradigm is odd and strange to get used to, I immediately likened it to event-driven Windows programming -- which is what I do for a living. A Windows application UI is, in a way, just a massive display of interrupt widgets linked to many, many ISRs. The fact that they need to be used more carefully and thoughtfully in the MCU world was just sort of common sense to me. I leave my "sloppy" work for PCs with massive processors, huge clock speeds, and GBs of RAM...
I'm not sure if you mean a periodic auto-save or an auto-save every time the sketch is uploaded.
I'd prefer the latter, as that keeps what your chip is doing in sync with the code, and acts as a nice checkpoint for saves (for me, anyway, I am a change-try-change-try sort of developer).
I once spent an evening working on a sketch, and for the last save (upon exit) I said "no", because for some reason I assumed it saved when a sketch was uploaded. Needless to say, I lost a bunch of work, and while my chip was in a pretty good state, I didn't know how to dis-assemble the code back to source (if that is even possible). Auto-save upon sketch upload would be very cool, and it could be a preference.