Yes, ... sometimes. It's clear that YOU don't care. It depends on how you define "works" though. I suppose it doesn't matter if your bus signs don't function 5% of the time, as nobody will notice.
BULLSHIT. there has been lawsuits on this subject.

However, those reset chips don't help at all during the power-down transient. Kai's initial comment shows that the oscillator runs on until the Vcc is quite low.
Not you are babbling. if the chip is in reset who cares if the oscillator is running NOTHING IS GING ON when the chip is in reset.

This suggests that the rise time of Vcc might be a factor.
how come you are arguing against using a supervisor with arguments for using it?
yes, there is a risetime requirement when working without a supervisor one datasheet (grabbed randomly) specify VDD Ramp Time VDD = 0 V to VRST — — 1 ms and digging into the datasheet it says "If Vdd rise time exceed 1ms an external reset device must be used"

I'm simply pointing out that it's the on-board FLASH that's the problem on which you focus, rather than the RESET. The runaway MCU is an issue even if there isn't any FLASH.
agreed totally, glad to have you on board.
Your argument "why is a supervisor needed" is the same as "the bacteria is the problem, there should be no need for penicillin".

I don't care how many unverified and potentially faulty systems you've shipped. I might care about how many you've subjected to and had survive the appropriate 1000-hour (about 6 weeks) 100-piece temperature and voltage controlled testing

You have no idea of what is reasonable and what is not, do you? Yes, I have shipped systems that failed; however the reason for the failure has been diagnosed and taken care of. I take input from many devices that "for disclusure reasons" are not available to me until the system is installed on a bus. As to your VERY SUBSTANTIAL 'testing procedure' just one comment: "I am not making equipnebt that can threaten life or limb". The testing procedure for a new release takes about one man month. I just visulaided you "testing procedure implemented here" we would have 600,000 signs sitting in a hothouse - some picture

So, go ahead pour leaded gas in your new car, burn the engine and complain "why does it not work, it used to"
I can't guess what you've been smoking ... <sigh> ...
No illegal drugs in my system ever; however where is the difference between putting leaded gas in a new car and running a new chip with a RC reset. Your claim is "I used to work, why does it not work today?" so the analogy is valid.

I agree that the problem exists as much if not more during power-down than during power-up
WOW, twice on one post you agree and make a valid statement.

The RESET IC can't help during power-down, though, since it is not specified what the MCU does while the power is dropping, nor is it specified what it does in response to RESET when power is dropping.
Now it is you that "must have been smoking" the behaviour of the chip when in reset, which the supervisor will provide during power down, is documented in each and every '51 datasheet I have laid my eyes on.

That part is EASY to fix, though. One simply puts a transistor on the oscillator and stops it cold during a power-down.
that would lead to undefined states on the port pins. with a supervisor chip reset the states are defined.

As Lynn's said, the RESET is just an NMI
sure for Richard, it is. for the rest of us that have discovered derivatives that are static, it is not.

Erik