My main concern is that the instructions to write to the EEPROM are still in the flash
As stated before programming eeprom/userrow/flash only at programming time eliminates any eeprom writing code.
Here is what has to happen for the new avr to program eeprom at runtime-
1. the page buffer has to have a byte written to a valid eeprom/userrow address,
2. a specific value has to be written to a specific register (ccp)
3. and within the next 4 cpu cycles a specific nvm command has to be written to a specific nvm register
without any of these coded in flash, its not happening, but having eeprom writing code inside the mcu means 1/2/3 are happening somewhere.
Additional differences the new avr has, which would apply if you were writing at runtime-
any nvm write is aborted at any reset (old avr will continue the write through a reset, assuming power level is above some point)
the page buffer is cleared at any reset, and an nvm write with a cleared buffer does nothing but produce a write error
any write to an invalid address will not write to the page buffer
Both old/new have to deal with write errors at runtime, and decisions have to be made on what to do when errors occur.
I would guess the biggest source of problems for the original avr (at the 0 address) is the continuation of the write process through resets- bod probably not set and/or startup timer not used, maybe cpu speed is high and still in a voltage range not suitable for the speed, an eeprom write routine is in flash and started, the voltage bounces around the Pot threshold where the mcu goes in/out of reset, the write process is started and continues through these resets, a reset does clear the addr/data registers which the write portion of erase/write now uses, hence the writing of 0 to address 0.
The new avr can also have problems where writing is interrupted, but the write will abort at a reset so probably less likely the write was far enough in the process to do 'damage'. Obviously it depends on where these resets takes place, and the new avr can still get into a place where the erase part took place but was reset before it did any writes, so can end up with an erased byte (or bytes since it uses a page buffer). The downside of the new avr with a page buffer, is if you are writing a bunch of bytes (up to page buffer size, typically 32/64 bytes on these avr), and a reset takes place in that process you may have a lot of corrupt bytes to deal with. The answer to that is probably just limits your writes so any problems are small/more manageable.