For the retro-computer implementations the simplest solution may be just be to tri-state the pins after the flash memory rom has been copied. The flash memory only gets accessed for a fraction of a second on power-up or after pressing a reset/reload button. Also the CPU is not involved in this, as it is stalled at the time, so an interrupt mechanism would be hard to implement.
For SOCs that use Xip to execute code from the flash memory, the interrupt mechanism may be the best solution, but the implementation might be difficult, particularly if the interrupt routine itself was in rom, and hence flash memory. Another issue for this case is that I would like to implement QSPI XIP at some point, and that would use the HOLD and WP pins.
When I was implementing the NES on the iCEBreaker board, @daveshah said that instead of copying the cartridge rom to ram (SPRAM for that iup5k board), it should be fast enough to run the code directly from flash memory (i.e. use XIP), but that would probably need QSPI to achieve the necessary speed. The same is also true of my NES port to the Blackice Mx. So at some point I was going to try QSPI XIP. SaxonSoc currently uses DSPI XIP, but not QSPI XIP.
I don't currently understand how the HOLD and WP pins are used for for their hold and write-protect purpose as well as for QSPI.
There is also a comment in @ZipCPU's code that he is not currently using QSPI for flash memory access as he is waiting for you to implement something in the firmware.
His exact words are: "The flash is running in SPI mode and not QSPI mode. I understand there's an issue with the QSPI I/O pins, and so I'm waiting on the board developer to address this issue before trying the QSPI flash controller again.". See the README for zipstormmx.(https://github.com/ZipCPU/zipstormmx).