'A lower priority may trigger . . . . have chipped in and messed it all up'
I can't imagine this was of much concern the the design using relays back in the 50's
Just the time element in closing the relay contacts would be far worse (a fair guess) than a microcontroller polling the input.
Even as a child I remember what appeared to be 'glitches' in the way the (now lights) mechanical horses advanced. It sometimes seemed a random group of three advanced, when two of the three still had a ball waiting to enter a lane. I wonder if this is how they got around that timing issue, by creating a diversion, perhaps?
Using cascaded/chained/extended 74XX148 8-to-3 decoders give some relieve in numbers of lines to watch, but at the same time pose a timing challenge because there is no registers that store the information - signal change - and Espruino may not be fast enough to catch who was really first, because the chip is a priority encoder. A lower priority may trigger but when reading a higher one may have chipped in and messed it all up. Furthermore, a detection of s'simultaneously in the same - very small - time window is not possible. The prototype I built in the reaction game can have this issue as well if something else runs next to the game, such as scanning / charlieplexing (when using something else than neopixels w/ storage info (which the prototype does not do).