If power is lost while a flash chip is erasing the block, robust software should assume that the contents of the block may arbitrarily change at any time unless or until the block is re-erased and an erasure cycle runs to completion. Even if the block still appears to hold old data, there's no guarantee that it will continue to do so for any length of time. Even if the block appears to be erased, there's no guarantee that programmed bits won't spontaneously "appear". I've seen a few processors with internal flash that included an ability to check whether bits were "truly" blanked or were "thoroughly" programmed, but I've never seen such functionality exposed by an external flash device.
If one wishes to be able to periodically store data to flash, and ensure that in case of power failure every update will either succeed completely or not at all, one must have at least three flash blocks, and define a protocol such that whenever a block is being erased, one can determine that based only upon the contents of the other two blocks. There are a variety of protocols for implementing this; I'll suggest a simple one here, assuming that the amount of information to be stored is a full block minus one minimum-size programmable unit, and three blocks are available, which I'll call X, Y, and Z.
Each block will have a "control" bits within it which is reserved for tracking validity/erasure status; I'll call those bits x, y, and z. During operation, the system will maintain the invariant that the block which holds correct data will have its control bit blank; the "preceding" block (X is preceded by Z) will have its control bit programmed. The control bits for the remaining block (the one "following" the one with valid data) will be irrelevant. If all the control bits are blank, nothing has ever been properly written; if all control bits are programmed, something has gotten seriously corrupted.
To write new data, erase the block following the one which holds correct data, then store new data into that block. Finally, as the last step, program the control bit of what used to be the current block. Until that control bit is programmed, nothing will care about the contents of the block that was just programmed. Once that bit is programmed, nothing will care about the contents of the block following the new block. Provided that the system has enough energy available to ensure that the programming of that one bit will either succeed or fail cleanly, reliable operation is assured in all power-loss scenarios.
Suppose that x is programmed, y is blank, and z is anything. Because the valid data block must have its own flag blank and the previous block's flag must be programmed, X cannot be a valid block (flag x is programmed), and Z cannot be a valid block (because flag y is programmed). Consequently, Y is the only block which can hold valid data. Block X holds the previous version of the data, and Z cannot be relied upon to hold anything. When it's necessary to store new data, code should start by erasing Z (regardless of whether it already appears blank), and programming all the data which is should contain. If power is lost at any time during this process, the system state will be the same as before it began (based on the flags, the contents of Z are presumed meaningless, so its contents do not affect system state at all).
Only after all the writes to Z are complete and it holds valid data should flag y be programmed. Once that flag is written, Z will be recognizable as the block which holds valid data since its own flag will be blank while the preceding blocks' flag (y) is programmed; the fact that y is now programmed will mean Y is no longer valid.
The next time it's necessary to store new data, block X should be erased and have data stored there; completion should be indicated by programming flag z. The time after that, Y should be erased and have data stored there, with completion indicated by programming flag x. It is vital that attempts to program flags x, y, and z either run to completion or have no effect, but those are the only operations which need to be "guaranteed atomic" at the hardware level. All other writes to memory will be done to a block whose contents will never even be looked at(*) unless they run to completion.
(*) The system generally won't be able to avoid accessing the invalid block, but the system's behavior will be unaffected by the value read.
BTW, if one isn't confident in the ability to ensure that flag writes run to completion, there are various approaches with redundant flag bits which might potentially help somewhat, but reliability will no longer be assured. Suppose, for example, that the system loses power while bit y is partially programmed so it will sometimes read as programmed but sometimes as blank. If on the first power-up, y reads as blank, the next update would erase Z. If during that erase, the system loses power and on the next power-up, y reads as programmed, the system would assume that Z is the valid block. If y had read as programmed both times, then Z would have been the valid block and the next block erased would have been X. If it had read as blank both times, then Z would have been correctly recognized the second time as being the invalid block. Although one might try to guard against these dangers by adding redundant flag bits, such approaches don't help much. One may design things so that it would be "unlikely" for partially-programmed flags to behave in troublesome fashion, but that is fundamentally different from the guarantee that if flag writes work atomically, nothing the chip could report for any other partially-written data would cause any trouble.