He's just going to have to learn this the hard way. He doesn't even seem to want to discuss details of how his own approach can be made more likely to succeed.
once you lock yourself, why would you do a "partial unlock"?

So far, there's been no detailed discussion of how he intends to move the data into his MCU, and from there into the EEPROM. At one point, he was intending to synchronize the data transfer between his PC and his MCU by using an interrupt. I don't think he ever considered interrupt latency. At another point, he intended to stop the oscillator in order to allow for the PC-generated delays, but never considered the rather lengthy start-time for the oscillator.
I have yet to see the first post from Mike that show him even having a glimpse of appreciation for timing. e.g. he is using a 250nS EEPROM with an 18MHZ crystal, if I remember right that is exceeding the timing conditions (it's been ever so long since I did anything with external code memory, let alone a 12 clocker) someone may correct me or confirm here. That he uses an 18MHz clock with a device specified for 12MHz max because 'it works' does not leave much hope for his 'design'.

I'm convinced it would be easier for him simply to program the EEPROM from the PC while holding the MCU in reset.
Accepting his "ROMofobia" I suggested that long ago but, as usual, Mike replied "that is not what I want". It could be done with a latch or two and a few gates.

His earlier post hey, if I get this working perfectly, I ought to sell the board to you for big $$$, just to prove that it can work!
Shows that he thinks the fact that showing something 'can work' has an inherent value. Well a buggy-whip 'works', but with the popularity of the automobile the inherent value is zero.

Erik