In general this shouldn't be a problem, unless the receiver saturates due to a relatively wide time aperture. So long as the receiver remains linear and temporal/spatial/code filtering is operating properly, it shouldn't be a problem to have 1000 vehicles in range. Because of the truly absurd bandwidth of an optical system (100THz relative to GHz radio) it's possible to keep other systems out of band.
One advantage is that the average brightness will drop with a square-law from the other sources. This means that sources more than several hundred meters should have rapidly dropping effects on SNR. That doesn't mean that you couldn't do a particularly bad job of designing the receiver (intolerance to interferers) or a particular good job of designing a jammer (knowledgeable intentional interferer).
Thankfully the large physical size of the car means that the amount of sensor data is going to be at a maximum when you're on a busy highway and fairly minimal. Something that is constantly modelled today.
It's a very interesting question especially if self driving motorcycles take off which have the ability to move in highly unpredictable ways.
With flash LIDAR, the duty cycle is very low. A ranging cycle is about 1μs, while you might cycle at 60FPS. The chance of interference is only about 1/10000 for each ranging cycle. If you put a bit of random jitter in the flash timing, you can avoid accidental repeated interference. You'll get a bad frame once in a while, but if the frames on both sides of the bad one look similar, you're OK.
You can tell if someone is aiming a big light source at you; all the pixels show the same range, probably zero.
Those rotating machinery Velodyne things may not be as immune, but that technology isn't going to be high-volume.
Doesnt this limit you to at least a 50 ms response time, before your CPU can "trust" the data? (before/current/next required to smooth before handing off to processing?)
In the odd case that the data is clearly garbage, you'll just drop it and keep going as before (so you add a frame to the response time at that specific moment).
In the general case of data affected by noise, it shouldn't be a problem: These things run a simulation of the external world, and every new input frame is never fully trusted, just used probabilistically to update the simulation. It is expected to carry noise, so if your sensors would tell you something like "a pedestrian in the sidewalk just jumped 10m in the air", you'd deduce "the guy most probably has kept walking as he was doing before, he possibly jumped instead, or he might have changed directions instead".
