Philips' and Atmel's RD2s and alike also enter into ISP by pulling down PSEN (and having /EA high etc.). They then vector to an address given by a special FLASH byte (to allow for custom bootloader) - by default FC00 - the "bootvector loss" refers to unwanted rewriting of this byte, effectively committing "ISP-suicide". Erik's wonderful workaround (backdoor) is to reenter ISP from the very start of user program upon activation by the user (holding down an input), but you need to do it from the start.

I also don't take for granted that the "lost bootvector" is a consequence of improper reset. I have my own reasoning, but that's a longer story.

The ISP entry for P89V51RD2 is also an issue - if it gets reset while some serial stream is thrown at it, it can autobaud falsely and never enters the user code. Not to mention, that the datasheet does not specify exactly how long is the waiting for autobaud. From this respect the break is a better method, IMHO.
There is also a "suicidal" element built into the P89V51RD2s bootloader - attempting to program it as P89C51RD2 you switch it into "soft-ice" mode, which is rather complicated to exit... There is an upgrade downloadable from Philips website fixing this (and I hope this version gets burned into the fresh chips now), but most people discovered this after they "locked" the chip...
(Speaking of P89V51RD2, the bad surprise is, that once you activate the x2 mode in ISP, you cannot deactivate it - only using a parallel programmer).

There are, except the mentioned, problems with the autobaud routine, with chosing the proper baudrate for given crystal (or tolerating a certain success-rate). Some autobaud routines also have an inherent imperfection, they can detect wrong speed if you throw a continuos stream of Us with spaces between them during reset.

The ISP entry for the LPC series is again an another issue - you need to apply relatively precisely timed pulses onto RESET - all the beauty of UART programmng flies away. Of course you can use a couple of other methods - but you need to think on it before you program the chip for the first time.

The documentation of ISPs is also not always an open book, for example in an older revision of Atmel's AT 89C51ED2/RD2 datasheet, some of the commands got mixed up and others omitted (maybe it was IAP, but that's the same case). Also, there are sometimes strange requirements covering up for possibly hardware flaw (e.g. the P89C51RD2H requires to repeat the erase bootvector+statusbyte command 6 times in a row).

Also, the bootloaders have sometimes hidden (unpublished) features, e.g. the LPC9xx has a readback function, which is undocumented.

Maybe it is mostly not about flawed bootloader software, but it has its issues.

And again, don't take this is to say SPI-ISP is better in any way - I just did not experiment with it so much (yet).

Jan Waclawek