I hadn't seen the new proposal for additional traffic on the NMRA standard side of the equation (which shoudl then work with ANY DCC system, not just NCE), however there is no easy way to make the DCC track bus bi-directional without making major changes. Digitrax has had that for years with their Transponding which sort of works, and Lenz has theirs which they gave to the NMRA but in some ways is even worse as far as modifications - it REQUIRES the command station to stop sending packets for a period of time to allow the decoders to respond back. Only Lenz command stations even have this feature today, and as far as I know Lenz and TCS are soem fo the only oens making decoders that can handle Railcom. On the Transponding side, only Digitrax has actual transponding decoders, and only SOundtraxx decoders are truly comptible with it (ie, run locos with some other brands of decoders and transponding fails).
This just isn;t practical, at least not with anyone's proposal so far, without a radical change to the DCC track signal. For one-way com for a signal display, there's no need for any changes, the existing accessory command protocols are sufficient, but to report back block occupancy states, forget it. Honestly? Sounds like NCE trying to figure out a way around the shortcomings of their cab bus. If block occupancy reports came back via the track bus and not the cab bus, then that information could be stored inside the command station and read by a computer interface, unlike information fed in via the cab bus.
Perhaps DCC-Next with be designed from the ground up as a bi-directional protocol. However that will be a completely new standard and for the most aprt incompatible with current DCC standards. So once again a massive shift - but this time the affected installed base is many times larger what it was back in the pre-standard days of command control systems.
And yes I also know about the NCE signal controllers that have their own bus - great, so now I need a track bus, a command bus for additonal boosters, a cab bus for throttles, and a signal bus for the signal system. I thought the point of DCC was simplified wiring? With Digitrax thre are but two - track bus and Loconet, which handles boosters, throttles, and detection and signalling.
ANd I will finish up by saying the only alternative to Digitrax I ever even considered was NCE< because it too is expandable and actually does pretty much everything you could want. In the end it was Loconet and the peer to peer nature of the bus that swayed me, along with the huge choice of third party and DIY options for devices to connect. I've built and used some of the DIY options, my one computer interface is the Hans DeLoof version of the Locobuffer, and I have a couple of Hans' LocoIO board I built to play around with input and output connections. Right now there's a guy on the Loconet Hackers Yahoo group working on a rather interesting discrete signal that you woudl just plug in to Loconet, however I have a feeling the final cost of components will be a bit high per signal since a microcontroller capable of handling lots of signals is only a few cents more than one with just enough ports for one signal. Kind of like the Hare decoder for Tortoises. It's convenient, but for a few bucks more you can build the same thing but have it capable of running say 8 Tortoises, it would just be a standalone board though and not something that conveniently clips on the Tortoise.