Lots on ETCS...so one wonders, that extra 'c'...for 'conventional' signals. Is this a half-assed compromise since the host railways and ML themselves don't wan't to bear the expense of doing this 'properly'?
"Doing it properly" means having the right interfaces between CP, CN, and VIA signalling and information systems. Imagine what will happen once ML has its own control center when a westbound VIA train approaches ML territory at Durham Jct. First of all, the signalling systems need to interface in the field so that the correct indications are passed to the CN signalling, which may give multiple blocks' worth of advance indications before the first ML controlled signal. Secondly, the CN RTC's console and supporting information systems already hold data ("tags" is the term) about that train. You want the CN console to pass that data seamlessly into the GO system. You don't want GO's RTC having to key all that data into the GO system every time a VIA train comes into the picture. Similarly, VIA has information needs and you can't have VIA trains disappearing into a void when it hits GO territory.
ML may in fact install pretty nifty new train control on its own lines, but where GO operates into or out of other railways' territory the systems have to accommodate everyone's needs. So yes, it includes conventional system design. Plus, much of the current signalling is close to brand new. Verster is not about to sign a purchase order to tear it all out and install something else. The enhancements will be add-on to what is there in much of the system.
Some lines may stay with what they have for years to come.