Surely it's possible to create a proper ROM writing function that first makes a copy of all the sectors a desired write would affect (however that is done, from RAM or directly from ROM if that's possible), then inserts the data we want to add in to that copy, erases those sectors from ROM with EraseSectorOfRom, and then writes the entire modified data back in using WriteToRom...
In theory, but in practice remember that when CHDK is running, most of the Canon OS is running from ROM, and there is ~100 tasks running, interrupts, watchdog timers and so on. Some parts of WriteToRom and EraseSectorOfRom are themselves in ROM.
Bad Things will happen if the Canon OS tries to access between the erase and the write completing.
The code that actually interacts with the flash chip is generally(?) copied to RAM and runs with interrupts disabled, but executing the entire erase / write cycle without involving ROM or having interrupts handled would take significant work at a minimum.
Canon firmware updates presumably (I've never actually bothered to reverse engineer one) avoid this by including all the necessary code and running entirely from RAM, but in general, CHDK doesn't have this capability, because all the code to interface with the hardware is in ROM. You could theoretically modify a Canon firmware updater to install custom modifications, but only for the camera it was originally intended to run on.
And does anyone know what the C function definition of EraseSectorOfRom would look like?
It fiddles with the values and calls some function (usually in RAM) which writes some values to some MMIOs.
Note some cameras have EraseSectorOfRom while others have EraseRom, which seems to correspond to somewhat different implementations.
Also, some cameras have GetRomId which appears to query the flash hardware. If the flash chips can be identified, there might be data sheets or other useful information.