I would think the Bluetooth latency would be similar but you could use a XBee radio in pass through mode where the PIN on one XBee radio is mirrored on the 2nd XBee radio. Or the RFM95 radios to do the same thing.
I’m not sure what the latency difference is between those 2 options but they are options for wireless pin change communication.
@Jimmie, perhaps the question should be, what latency do you need? As I see it, the serial laser sensor has a communications latency and the Xenon to Xenon introduces latency for any wireless or ethernet protocol used. Add to that the missing Xenon/Xenon time synchronization and “a lot of processing needed”. You may need to rethink how you approach this problem.
Thank you @peekay123. Yes, sure.
Without losses, we expect the time difference to be about 75 ms. Since we need speed to be within 10%, that leaves only 7 ms for latency.
I am hoping that using a hard wire and an interrupt will work but agree that it may be too tight …
That's a velocity of 400 feet per second (30 feet in 75 ms), or ~275 MPH.
I'd agree that a wired solution for (1) Controller/MCU is your best bet.
Then the response time for your (2) sensors that you select become the bottleneck, not communication latency.
You could set variables with micros() in your ISR instead of millis(), but that's probably overkill depending on your sensor's response time ?
The 30 feet is the distance from the sensor to the object not the distance between the two sensors 
The distance between the two sensors is about 150 cm.
Why not use the TX/RX of one and hook it up to the RX/TX of the second and just use Serial1 for the communication? I use this to have Feathers and Particles talk, and it works fine. I even wrote a rudimentary class that allows for asynchronous communication between the two.
Because using the Ethernet Feather disables Serial1.
Any two pins will work, but it might require software serial.
Not really. Software serial is not supported on mesh.
Mesh has nothing to do with software serial. Just a tx/rx pins.
Software Serial doesn’t require extra hardware. It is software, as the name indicates. It doesn’t need a UART.
Thank you for trying to he helpful.
The problem is that the SoftSerial library requires a Timing library that has not been modified to work on Mesh devices "yet".
Please see below:
There is a Particle Software Serial library. It requires no additional hardware. It just needs 2 pins as I said. https://build.particle.io/libs/ParticleSoftSerial/0.0.11/tab/example/PSS_SimpleTest.ino
@Jimmie is correct, ParticelSoftSerial relies on hardware timers (internal to the controller) for the exact baudrate timing and there are not enough free timers on the Gen3 devices - hence ther is not Soft Serial implementation available for Mesh devices - irrspective of how much you insist there is.
Very good. I guess then @Jimmie will have to switch to a pair of Xenons and an Argon or a Xenon and an Argon which will free up TX/RX for Serial1 communication. Even a Xenon/Feather combo or Argon/Feather combo would do the trick.
Snark not required.