I am really quite curious about the specifics of the issue, but I guess it's wishful thinking to suppose they would divulge any details, as it could make their technical competence seem even worse. If it were possible in some (most?) cases to simply cancel and proceed, then it sounds to me like the conditions that bring up the screen were on the aggressive side -- that is, they designed it intending to err on the side of more false positives, thinking they would have fewer customer complaints because a reset would allow the device to recover and rebuild its database, etc. into a consistent, "within the boundaries" sort of state. If this line of thinking were the case (this is all just speculation on my part), it would seem their plans backfired on them, as users were more frustrated at being bothered by the screen so often (and the long reload times, in some users' cases).
But who knows what problems merely cancelling the reset would have allowed to fester in the device's system files. Certainly, any good software should be able to gracefully handle malformed data. For all we know, though, the 1.9.10 update did nothing more than alter the reset screen's trigger conditions so that it wouldn't appear as much (or at all?), even though nothing was done to actually address any data handling problems.
Perhaps just something to stop the PR bleeding, and bide the dev team time to actually fix things.
But, again, just conjecture on my part.
