An Idea that might be a bit off the beaten track, but you never know...
How about a box containing an RFID reader (e.g. SL030 or SL031 from http://www.stronglink-rfid.com/)? Put an RFID tag into every engine and cart, and put the reader next to the track, and you can track who's passing by. I know the SL031 from my job, it has a simple 3.3V UART interface, the documentation is OK, and if you've got a problem those guys are very helpful.
The SBrick can drive NXT/EV3 motors, but only after hacking the cables.
Since SBrick has no electric input at all, supporting any existing sensors is out of question with the current version.
However.
We do plan to create sensors, and/or build a similar brick to support existing (probably wedo/nxt/ev3) sensors. This stuff is only in our heads now, so don't get too excited too soon, but it's definitely in our vision.
They still have normal I/O ports and they are much cheaper than NXT/EV3 (okay, the shields are very expensive). In addition to that, you can use daisy-chaining with the EV3 so that you can use the sensor- and motorports as if they were on one brick. Except of that you can also use multiplexers.
I think that a controller with 8 Mindstorms ports would be very expensive. In addition to that we have enough devs that work with the Mindstorms. I think that the sbrick team should concentrate on powerfunctions.
Those shields suck.
Fisrt of all they use the L293D motor driver, which is known to explode under the moderate load of LEGO motors.
Secondly, those shields offer no significant number of ports compared to the original NXT/EV3 brick, and cannot be stacked, so what's the point of using an arduino or an rpi with those shields?
If you like to code your projects in C, Java or Python, those languages are already available to the NXT brick.
How about a smart brick for NXT/EV3 sensors and motors?
I am thinking about a replacement for standard NXT/EV3 smart bricks, which are quite limited in terms of number of ports.
There are several issues in designing such a large board, for example the number of I2C buses.... which is unusual to have more than 4 on a common MCU. Perhaps this can be solved with I2C switch ICs. Also, for every NXT/EV3 motor port, 4 I/O lines are required, one H-bridge motor driver, probably a PWM driver, and two lines for reading the rotation out of the quadrature encoder.
It is a challenging project, but this would allow for very large projects to be built with it.