Perhaps saying "it's trivial to solve" might be the wrong approach then?

> hey are complaining that they can't implement rolling block scheduling because they don't know where their cars are or how fast they're going, and they're saying they need to spend an absurd amount of money to remedy that situation, and that's what I'm objecting to.

Collision avoidance is an inherent part of scheduling and tracking. The reason they run so much distance between trains in New York (and almost anywhere else) is almost entirely because they're allowing enough distance for the train to stop without hitting the vehicle in front of it. Locating the vehicles with enough precision and accuracy is more than simply sending a signal — although the inductive loops used by Muni work well enough[1] underground until the trains (or, most recently, contractors) themselves destroy the loops. CBTC in by its very definition is more than simply vehicle location.

While I'm mostly in the camp that BART is wildly incompetent, they tried to reinvent an even simpler train control in the 70s and demonstrated quite explicitly what happens when you underestimate the problem at hand. More recently they've spent tens of millions trying to come up with a CBTC (and so has Caltrain) and failed completely. If you know something they don't, talk to a lawyer and file some patents as you could make a mint.

1: For the first decade or so after Muni went to a CBTC[2] setup even something as basic as the transponders were huge pain points and you'd see massive failure rates over time leading to all sorts of problems underground.

2: The big selling point of the CBTC setup Muni chose was that it could be installed with a minimum of disruption AND that it used cheap, off-the-shelf parts. Alcatel/Thales abandoned that design almost immediately after pawning it off on Muni.