Hi. I think we will be soon in a similar case and require a method to offer field upgrades with a solid solution. Working on a complete eco system for home automation but still working out the building blocks.
I think you have many potential ideas you can follow so will give it more thought but for the immediate feedback:
1) Your XMOS device is currently the SPI master. This SPI master is chatting with your WIFI module. It should be very possible to allow for the same SPI master to select an alternate SPI flash. So, the XMOS code will use your WIFI module to read in the new firmware and then copy this firmware onto the alternate spare flash device. Once the firmware is considered to be uploaded onto this alternate flash device, perform a CRC validation to be sure the firmware is 100% correct.
2) After a positive verification, signal the external low cost alternate SPI master (EFM8, STM8, STM32, etc - all under $1 USD). Then this external CPU will take over the same SPI bus and place the XMOS into RESET. Then this new SPI master will copy the alternate SPI flash contents and apply into the XMOS device using the pins defined by XMOS (ie. you are parking the XMOS CPU into reset = hi-z and can now assert external logic levels while the XMOS device remains parked via the RESET pin). Once the new firmware is loaded, release the reset of the XMOS CPU to run off the new firmware.
This convoluted method should work fine but needs to be carefully thought out and may require the use of muxes (ie. to steer the SPI flash between the XMOS CPU and the next SPI master). The key benefit of this approach is that you can erase the entire internal flash of the XMOS CPU since the external SPI programmer (EFM8, etc.) can insert the code from scratch.
These are just ideas and there are others that may be more practical.
3) While driving to work, thinking about - how large is the internal flash inside your XMOS CPU? How much is free after your code? If there is enough spare room, you could just download over wifi the new firmware, apply into the free space of your flash device and then reboot. This is the DFU method where if the 2nd image is properly stored into the flash, the ROM inside the XMOS CPU should allow to boot off the 2nd image. However, this method is restricted to the amount of spare room left inside the flash device.
If you are designing a new product - consider to leave room for a proper footprint of the flash device for EXTERNAL use. Then you can purchase XMOS CPU without internal flash (if practical) but can be as large in density as you wish. That is the approach we would take. Internal flash is great but limited to what the factory gives you, better to use an external flash so you can grow as your code size expands. The key here is that the single flash device could hold multiple copies of your firmware.
Again, just ideas so take the approach that is best suited for your project. Based on costs, believe the external (larger) flash idea may be the winner with DFU.
The use of the external SPI programmer CPU is very possible but you will then need to review how to program this fresh and new CPU? For EFM8, we wrote our own code to program in-circuit after soldering. Or you may need to apply external JTAG pins for the CPU (ie. SWD for STM32 devices) so you can program the micro using pogo pins. But, what if you wish to change this external CPU's code? For this reason, you will need to make the XMOS CPU act like a programmer for EFM8 / STM32 or whatever CPU you have in mind.
https://www.xmos.com/published/dfu-user-guide
The summary of the external CPU idea is that this extra logic is acting like a dedicated SPI programmer that you will be including onboard.