Lets take a step back for a minute.
There is nothing new in the inter-connection of the CS2 to the 6021, the CS1 or with, other CS2s or with PCs (including smart phones as mobile throttles)
The CS3 appears to be a simple variant of the CS2<->CS2 inter-connect, which is via the system bus. (using the 60123 cable)
As to the marketing blurb that neglects to include the 60213, this may be a typo. . . . . .
However I think there is a need to differentiate between "will work" and "will work with limitations"
To this end I note the following.
The 60213 is
NOT the same as the 60214 (As with the 60173
NOT being the same as a 60174). The track output for 60213 and 60173s needed to be isolated at BOTH the rail(Brown) and stud(Red) when crossing booster sections.
Refer
http://www.maerklin.de/d...ationen/booster-upgrade/So in this case the limitation inferred
may be that the 60213 is not 100% compatible as a booster. If may (should?) be operationally OK as just a slave throttle or layout/memory console. BUT there may also be a software/resource limitation whereby the internal memory/processor is not able to be updated to a level that will allow
functional interoperability. I would hope that a software connection would at the very least be be possible, but it maybe of reduced function if there is a resource issue.
Tom has already referred to the fact that an ethernet connection does not provide for 100% in sync track signal (Ethernet is, in this respect asynchronous , and IP is a loosy protocol) . This is why the (early) architecture diagram that included the CS1 connection, via an ethernet connection, specifically showed that its section of track was NOT connected to the layout controlled by CS2 and boosters. While the content of the signal information may have been the same the pulses/timing could never be guaranteed to be sychronised.
It is imperative that, at any transition from one booster section to another (including the CS2/CS3 internal booster), the track signal be in sync and only a fixed clock via the system bus will provide for this. You can forget about a network communication protocol ever achieving this!
For those that care, you may want to research the Connect-60212 product - This was an adapter for the CS1 to connect to the CS2 via the system bus (e.g. see in the 2008/9 catalogue). This may have provided the in-sync alignment we are talking about but it was never ever delivered. instead we ended up with the TCP/IP connection we have now over the ethernet.
The 6017(6015) legacy support also needs to be analysed. . .
Depending on which version of information you read, interoperability, like the original CS1 interoperability, was depicted with a totally separate section of track - i.e. you should not run a train from a CS2 track section into a 6017 section.
While we know , from experience, that this "can" be made to work it has its operational problems. Also we have to appreciate that the CS2(or CS1) with its mFX read-back capability puts an onus on decoders to send information onto the track that the 6017 was never designed for. So while the 6017 and the locomotiev decoder may be able to "tolerate" it, there is prudence to be had from relegating the 6017s use to a separate circuit (e.g. the k83/k84 accessory bus)