Buncha observations, from the point of view of a fellow model railroader. I'm building my own signal/detection/control system, though my layout is DCC. I looked into various bus systems and decided I did not want to deal with the complexity of things like CAN - so I am using RS485 with the CMRI protocol. Yes it is single master - inputs are read by polling the controller to see the current state, not by the input pushing data to the master. This works just fine, and is plenty fast enough - even on some REALLY huge model railroads. The protocol is dead simple - and I'm taking a few shortcuts so that some of the ID and config packets are not needed, by making each of my nodes identical (in software anyway - I am not populating a PCB with 4x 16 bit output latches for a node that only needs 16 bits of output. However, the PCB and the software will accept 64 bits of data, just only the first 16 will actually appear on physical outputs for the smaller node.
There is in this design something more complex than a micro as the master - it's a full blown PC. That software will be written in VB.
In the original CMRI articles in Model Railroader magazine back in the mid 80's, there were two versions of loco control for standard DC locos (there was no DCC at the time, but there were some command control systems available). In one, the computer drove a set number of throttles, say 4, which had their outputs switched to various blocks as the trains moved about. You could also use user controlled throttles, with the computer and the CMRI nodes applying a given throttle's power to the appropriate blocks. Option 2 had a computer controlled throttle for each block, similar to the one design posted above. This allowed for both full computer automation or the user could run a simple 'throttle' device that fed in to the computer which then applied power to the blocks as needed.
Note that the power is not applied to the next block at the moment the train crosses the block boundary - this happens well before the train gets there. You do not operate trains without at least a one block separation. If a train is in block 1, the system should already determine that block 2 ahead of it is clear and assigned power to that train's throttle. If the block ahead is occupied, then the train is stopped - well before the electrical boundary. There should be no issues with one truck (bogie) being across the gap and the other behind it, passing power via the loco's internal wiring.
The data protocol is open - you would have to make your nodes correspond to known designs if you want to use commercial (well, written by others) control software, or you can do what you like and write your own (as I am doing). There is an Arduino-based node available commercially, the code is open and the schematics are published - I am altering that design to use the SPI version of the IO Expander (MCP23S17 vs the commercial product's MCP23017 I2C version) and also fixing which chips are inputs and which are outputs (eliminates the config packets in CMRI). For actual point movement, I have a separate design that I posted here previously that has both control input from the node as well as local pushbuttons, the button lockouts being active low so that if I don't turn on the master computer and the control nodes, I can run trains by myself and just use the local buttons to line the points. Mine drive a servo, but it could be adapted to a stall motor or solenoid. It also drives a relay to switch power to each frog for maximum reliability.