Do you mean that ISP is accidentally entered or, on the flip side, ISP mode won't activate when it should? If so, in those cases, how is ISP mode supposed to be entered?
Philips has had a lot of problems with the Rx2H and 66x derivatives when used with a RC reset. They are faultless when used with a proper supervisor. The RC reset has, in many cases, caused these chips to lose a vector that is used when Hardware (I call it "funnly levels") is used to enter ISP. This, of course, is related to Flash and reset, rather than ISP.

I'm not sure if any derivatives do it, but I'd be skeptical of using, say, a long break signal on the UART to enter ISP mode. I can see potential problems with that. But if you use another pin to initiate ISP mode on reset, such as PSEN like TI does, it seems like you'd be pretty safe.
The advantage of the long break is, of course, that you can activate ISP without opening the box. whether it is "safe" or not I have no opinion on at this time.
Anyhow all problems with the Philips chips are gone when using NoTouch.
The latest issuances from Philips (the 89V51.. chips) use a different method: if they see a 'U' within x clock cycles after reset, they enter ISP.

My basic philosophy re ISP is that if I can not rely on a customer, computer-illiterate beyond basic PC skills, to upgrade the code, it may be ISP, but the value is only nominal. If I have to send a technician, replacing a socketed chip is just as easy.

I actually parallel program ISP chips in manufacturing because it is faster, but the value of being able to send an e-mail with "install this on your PC/laptop" and instructions instead of a techie is enormous. We have calculated that to send a techie cost $500+ on avarage and that is using discount airlines.

On another note: my next issue will have a Cypress processor working as an USB master interfaced to 6 '51 processors and a keychain disk as input. I hope to use IAP and this to make a "seamless" program update procedure.

Erik