The latter involves writing to the NVMCTRL registers - in fact, with a value (2) that means "Erase Row", but in a slightly different register...
Except you also need to have a specific cmdex key value with odds of 256:1 against, in addition to any other odds in place to get to that point.
That blog post link is talking about a d21, and this common (I assume) uf2 bootloader appears to think the d51 is the one with the problem (and not the d21)-
https://github.com/adafruit/uf2-samdx1/blob/master/src/main.cWhy would it be a problem on the d21 in one instance (blog post), but in some other often used bootloader its only a problem in the d51 ?
I'm inclined to believe the bootloader code is involved somehow in any case (a common theme in both), and the fixes described are simply preventing any corrupt flash reads with the resulting possible inadvertent branching into bootloader erase code. The bootloader is using the correct cmdex value, so should be the only place an erase should take place. Without any code in place to erase, getting the nvmctrl to do an erase by 'random' seems unlikely when you need a specific 16bit value to be written to one address (aligned) in a 32bit address range. This is all looking at the nvmctrl from the 'outside' controls, and maybe whatever goes on 'inside' can be a problem under certain conditions.
The booloader in the link above uses a 'double tap' entry, but does not distinguish the cause of the second 'tap', so its not hard to imagine that the second tap can come from a brownout reset (even before the brownout value was raised, although odds decreased when they raise the brownout in early code). Although you are now in the bootloader unintentionally, that still does not get you to a page/block erase.
Remove the bootloader, and maybe the problem also disappears. Those claiming the spurious erase problem/fix do not seem to have tried to test their brownout theory without a bootloader in place, which would be better proof since then no code exists to do any flash writing. I only have samD10's, and its errata suggests enabling manual write (manw) in startup to prevent spurious writes, which sounds like a good idea (and maybe setting addr to some harmless address as described in previous post), but a write to non-erased flash is not an erase (although just as bad, assuming page buffer is not in erased state).
The half page erase in the original post doesn't make much sense in any case since nothing is in place that can erase only 1/2 a block. If I was interested in finding out if this brownout theory was correct, I would take my stock d51 with bootloader/app in place and try to hammer the power as that blog post did. If you can reproduce the problem then you can get to the next step- remove bootloader, app only (recompile), do the same power testing. At least you can then see if the bootloader is somehow involved. If this problem has nothing to do with the bootloader, then testing can continue (wait states, brownout values, etc.). In any case, if this problem can be reproduced I'm not sure I would be happy with only boot protection in place, and would look into region locking also (erasing part of the app is also not good).
Although I don't see anyone claiming D10's act this way, maybe because of the small flash size, few are putting bootloaders in them and avoiding the problem. Maybe I should see how a D10 acts- create an empty main loop, first lighting up an led then setting speed to 48MHz with no wait states, fill up the rest of flash with a row erase function (simulating hundreds of bootloaders in place to maybe increase odds). Power cycle until led quits lighting up, or until satisfied nothing bad happens.