Just my $0.02...
Be careful with any while loops that could go on forever under "perfect storm" conditions. It's usually a safe bet that eventually your device will get into a state where comms will fail forever. If you're stuck in a while loop waiting for a successful send then you have no chance to detect or correct the error, and given how tricky it is to debug Arduinos you'll probably never figure out what went wrong. The device will just go silent, and a little while later the batteries will run out (because it's sitting there trying to send over and over). Do yourself a favor and put a fail-safe && retries++ < MAX_RETRIES clause on your while loop.
This doesn't speak directly to your case, but in a broad sense my assumption going in to any wireless design is that packets will be dropped, so I always design with that constraint in mind, rather than trying to design a system where no drops occur. For example, you might consider adding a "resync" timer that sends the current state regardless of changes every so often. So even if something is dropped you have a bounded amount of time where things are in the wrong state. I do this with my presentations: Every 5 minutes my sensors retransmit all presentation messages just in case the controller missed the first set, or the controller reset, or whatever...
Handling lossy comms is not usually too hard if you aren't trying to back-engineer that into a system that was designed with the assumption that messages would always succeed.
Incidentally, this is more or less the same as "UDP" vs "TCP" networking, if you've ever worked in that realm. So strategies would overlap pretty nicely.
