Official comment
The chip erase is only ever used as a fallback if there’s no system image found by the bootloader, sending it back to V19.
The sector erase would result in just a quick return since the chip would reply immediately with the status bit 0 = 0 (at least I’m assuming that’s the case).
The kicker is the write protect. The bootloader will try and set BP bits to something based on the size of the part reported by the JEDEC ID command – which this part doesn’t seem to support. So we don’t know how to set up two important variables based on the chip capacity.
So in order to support this we’d probably have to make an exception for it in the bootloader code, make an assumption about the size, and not write protect the chip since we require lower-half write protection. This leaves the bootloader and system image somewhat vulnerable to corruption.
Note that the 6000 does have the concept of user-defined persistent data that gets wear-leveled through FLASH based on blob size and allocated size. This is documented in the NC include file “Logger.h”.