While I believe some of the "bootvector loss" cases are related to improper reset, I am quite convinced (although I have no proof for this either), that in a system where a proper reset IC sits, this is not the case, even if the trip value would be slightly below VCC(min) specified for the mcu.
My - again, unproven - belief is, that the bootvector loss (and/or FLASH corruption) might occur when a glitch occurs in the supply and is not followed
by an active reset immediately, but I don't believe it occurs when VCC is kept within relatively tight tolerances (although glitches might still occur, depending on particular board design - e.g. if the reset IC sees heavier VCC filtering than the mcu).

But, I DO have a clear explanation for at least some of the bootloader loss cases, with an - I believe - acceptable proof (I think I have already mentioned it in the FM forum and Andy Ayre agreed with me that this might be one of the mechanisms):
Both the bootvector and status byte are erased when a bulkerase on the chip is performed. Weirdly enough, these two bytes are erased to 00 (rather than FF as the rest of FLASH does). And, what is more fatal, this is exactly the state of "bootvector loss" - the zero status byte means that the bootloader is NOT run at all; and the zero bootvector means, that the mcu starts from 0000h after reset, even if /PSEN is pulled low.
The internal programming algorithm does reprogram them automatically to the default state (FF for statusbyte and FC for bootvector), after the internal bulkerase has finished; but the bulkerase lasts for a relatively long time - up to several tens of seconds, which is practically infinitely long for a typical embedded engineer :-) - and if during this time power is lost, reset occurs (e.g. due to glitch/EMI not unlikely in typical manufacturing environment), or somebody impatient pulls out the cable prematurely, it is very likely that the status byte/bootvector bytes remain erased, or at least corrupted.

There is also a minor issue mentioned in the appropriate appnote (AN461) with the necessity applying erasing cycles to erase properly these two bytes in certain batches, so if you don't chose the proper version (H versus non-H) this might come up as a problem - but my specimen of H suffix chip did not suffer from this problem and apparently erased both bytes at the first attempt OK.
Another minor problem might have came up with inappropriate setting of the crystal frequency; the culprit is Philips here, as they did not explain properly that there is no need to enter the crystal frequency for these chips at all - you can look up here in this Forum the explanation of exactly this issue from a true insider.

I believe, that these mechanisms (and above all the interrupted bulkerase) account for more "bootvector loss" cases than the improper reset; although again I have no proof for this claim.

Nonetheless, _my_ conclusions are:
- the bootloader entry method in the P89C51Rx2 is crappy, and NXP mindlessly reproduced it in the new 'CV'
- the 'V's method (especially in the improved bootloader) is FAR superior to this; and, when designing modification to the chip, it would be a piece of cake to merge both (it's a single flip/flop to catch /PSEN status upon reset, and 1 line in the bootloader to evaluate this)
- the documentation of all abovementioned chips (sorry, but I think this is the adequate expression for it:) sucks (including, but not limited to, the crappy reset promotion)

JW