Typemaps will not work. They have jagged edges. Just imagine trying to move units down a long bendy terraformed wall. Guard would work even less. Attach unit may be used in a train implementation but it does not sound useful in the sense that the implementation would be harder if attach unit did not exist. The angles of the carriages would still require calculation, nothing here is for free.
I don't see how to write trains in a way that uses Spring to any significant extent. To rephrase; I don't think there are any tricks, nothing with typemaps, attach unit, guarding, move goals etc... All I can see is the 'brute force' approach. To get trains you have to calculate the physics yourself, do the pathing and control everything with movectrl. Spring can offer its services in the realm of unit selection, custom commands and anything non-movement related (primarily, mounted weapons).
If you someone was trying to make a train RTS I am unsure whether I would recommend Spring. It would depend on more details about the game they want to make. Spring does a lot of things for free (netcode, terrain, UI support) but they would be writing the movement logic themselves.
I estimate that it would take me at least a week to make a decent initial implementation of trains. This estimate was "at least two Ludam Dare work intervals" which turns out to be about a week. This does not include polish or later changes that become necessary. The code for trains would be at least a terraform-level gadget and widget. I estimate that I have spent around 3 to 4 weeks working on terraform but it may be more. My standards have grown alongside terraform so an initial implementation of trains would be harder than the initial implementation of terraform.
Trains are not looking likely from a technical standpoint. I do not want to spend a month and a month for me is many months for most people in Spring lua. I would like to see a train RTS though.
Have you considered a standalone game? ZK imposes many technical, mechanical and polish standards. Everything else in ZK has to interact with trains which is one of the great difficulties. There are many core assumptions in ZK which a train game may be better off ignoring. For example ZK tries to avoid grid bias; the effect where gameplay depends heavily on some underlying grid. Think Warcraft 2 compared to Warcraft 3. Or Crypt of the Necrodancer compared to Nuclear Throne. Almost all games have some underlying grid. Some try to minimize the effects while others embrace it to become a visible mechanic. I may have gone off topic. Regardless, trains are a lot easier to implement with a large grid for track construction and pathfinding. The complex mechanics of movement become a lot easier for players to reason about. Free choice of grid bias could be important in the design.
There will be lots of non-obvious design constraints that come from working in ZK. I am not going to try to separate and list them. But there are also many obvious gameplay/balance constraints. For trains in ZK to be worthwhile they have to neither overshadow ZK or be overshadowed (aka: not OP and not owled). This is another significant task.
