Yeah, there’s some counter intuitive logic to me in that example (still guessing I don’t understand the code correctly). I think that I should change my question…
When would the command t.setupLowPowerWakeMode(movementThreshold) fail to work? If I understand that, then I can write my own logic for dealing with it.
This provides one answer 
I know 
I meant more like, why would it respond with a zero? I’ve probably been thinking about the interaction of the devices incorrectly. It’s on the SPI bus, the command goes through the Electron, and if the SPI bus response is non-existent, then the command gives a zero, telling you the shield isn’t plugged in or significantly damaged. I’ve been framing the question in the context of the example, which still doesn’t make sense to me yet since it can fail and the command never gets checked again. I’m going to move on and just assume that zero means there’s a hardware problem that you need to physically inspect to correct.
I’m working on getting a threshold that is more sensitive for the wake. Seems like the lowest value I can use is 4. I looked through this https://www.st.com/resource/en/datasheet/cd00274221.pdf and can see that ACT_THS uses 7 bits of that register. I also saw a comment in an example somewhere else that a lower value is a lower threshold, makes sense. Values of 0, 1 or 2 seemed to disable the wake feature though. Thanks again for the help, and Happy New Year 
going to see The Mule now.
To answer that, you may need to look into the implementation of that function
Particle Web IDE Line 351ff
But as it turns out, that particular library would only ever return success - don't ask my why Adafruit has originally implemented it this way
However, since the actual setup is a multi step procedure it is (would be) good practice to check for each individual step whether it actually renders the expected result and if it didn't bail out of the function and report failure.
And hence checking the return value of the function (even if the current implementation never will fail) is good practice too - after all, the implementation might be extended and then your application can already handle it.
BUT, I'd actually not use the AssetTracker library but rather the more sophisticated AssetTrackerRK library.
In other words, if moving the device is what lead to it waking up from sleep (versus a timer), then awake would equal 1. Did I understand that correctly? It is always 1 for me from the tests I've been running.
I've been having problems with it never waking up. I think part of the problem was going to sleep with it the device still moving, but not enough to trigger my "bump" logic that keeps it awake. I'm rewriting that and doing more testing. That issue stems from what I've seen with it in the glove box of my car.
The other issue with it never waking up seems to be related to it being powered by the USB plug. I'm only ever using USB to charge it. I've left it on my kitchen table, powered by battery only, completely still and it would always wake up. However, if I was charging it via USB, there were times it would become non-responsive. No wake up from a bump or a timer. Had to press reset.
Are there any known issues with sleep and charging it?
Edit: And I have been using the AssetTrackerRK library since it was suggested.