high accuracy wireless clock coordination + data transfer
GPS may be an option outdoors (or with enough effort, repeated), but is fairly expensive and may have unreasonably long lock times.

Typical 433 MHz radios may not necessarily work.  The problem is that they have a tendency to resample the data - the cheap ones as they are regenerative designs which self oscillate and quench, the better ones because they have data slicers.  Typical bit rates (and quench rates for the regens) may simply not go high enough to give the desired time resolution.  It may be possible over an extended period of time to see through this and gain information to discipline a local clock.  But I suspect that with a low bandwidth radio one may need to get at things substantially earlier in the receive chain and do ones own detection / correlation.

In contrast, something like the 1 or 2 megabit/second modes available on an nRF24L01+ 2.4 GHz data radio could well give enough time resolution even after data resampling. I don't know for a fact how deterministic the receive path is with regard to time response, but it would probably be worth looking into.  And they are inexpensive and easy to work with for the data aspects.   Software interrupt latency can with care be within the timing requirement, but one could also wire the radio's packet IRQ signal to an MCU timer capture input.  Some BLE MCU's (at least those from Nordic) have heritage to the nRF24 can could probably do this as well.

In terms of wifi, trying to assign multiple devices the same IP address is a non-starter.  If trying to work through a formal protocol, UDP broadcasts would be a better choice.  But with something like the ESP8266 or ESP32, it would be better still to investigate the raw modes which use the wifi radio at a lower level than a wifi network would.