Octoprint says it is sending "N0 M110 N0*125" but RRF is behaving as though it has received "WiFi module is cN0 M110 N0*125". It's as though the message "WiFi module is connected to access point..." has been sent by RRF but either RRF or Octoprint or the USB CDC port driver on the PC has echoed part of it back to the input. Octoprint then sends the M112 emergency stop command.
I looks like this was the problem. All three of my printers have an OctoPi board which powers on at the same time as the Duet WiFi board. I use a DC to DC converter to take Duet VIN and make the power for the Pi board.
I just tested two of the printers by changing the Pi power source to a separate switch and now with the Pi boards left unpowered the Duet boards will cold boot like they should. I don't know yet how long the delay needs to be before the Pi power can be applied.
None of this was changed when I migrated to v3x firmware, it all worked fine on v2.05.
Also, now if I power up the Pi with the Duet power source off, the Duet will turn on through the USB power (from the Pi) and I do see the cold boot fault again.
So that't it! Now it is just a question of whether Octoprint or RR3 need to change anything and I will leave that question to others.