Neroden,
thank you for your feedback. It seems that a full system as I had originally described might be a bit much for a computer to handle with reasonable performance. Perhaps, however, the idea of using route fragments can survive in a simplified form: as now, we could just calculate city to city routes, and use the existing non-routefinding method to guess the speed of intra-city routes. The inter-city routes, however, could use route fragments in the same manner as I described in the original outlining of the application of this concept; the inter-city routes would be stored, and, whenever a pathfinding algorithm steps on a tile with a route to the same destination, it would stop looking and just append the remainder of the route to the end of the route found so far. Any thoughts on that method? In particular, is there any good use to which the information as to teh amount of traffic using any particular route could be put...?
As to city mergers; traffic under the new model is an interesting one. It might be possible to detect whether one city is contained within another for the purposes of traffic (check whether a town hall's city road is contained within the confines of another city, although that might require iterating through the whole city list for each town hall road), but the mergers idea is an interesting one all the same. The other thing with cities in Experimental is electrification - it might be tricky and unintuitive to have to have a separate substation in a city entirely contained in another city. Are you volunteering to code it...? 
I could probably code city mergers -- it seems relatively straightforward actually. It'll take me a while to decipher the city code though. Here are my design thoughts:
1 - merger is only triggered when the 'larger city' tries to expand its city limits. If it then contains a smaller city entirely (compare city limit boxes, I was thinking), the merger triggers. Alternatively, it could trigger when it surrounded a town hall -- this would require that the larger city then expand its city limits to contain the full city limits of both original cities.
2 - If someone tries to build a smaller city entirely inside a larger city, this should simply be refused, or better, replaced with an "enlarge city" order. There might be some trouble hooking this into the initial city generation code.
3 - Any open windows for the smaller city, the one going away, are forcibly closed.
3 - The smaller city is then systematically "destroyed" -- each of its buildings and monuments is transferred to the ownership of the larger city, each of the industries in it is transferred to the larger city, each of the road tiles (if they're tracked) is transferred to the larger city, each industry which gets workers from it is disconnected from it and connected to the larger city, it's removed from all databases listing cities, et cetera.
4 - The population and related numbers of the larger city are increased (if this hasn't already happened as a side effect) by the former population (etc) of the smaller city.
5 - The townhall is demolished and replaced with an appropriate monument ("Former Town Hall" I suppose) -- this is the only bit I'm really unsure how to code.
6 - The city objects, now disconnected from all databases, are garbage collected. The graphs and historic data for the former city are simply thrown away. If there is any leftover non-updated reference visible to the user, it is pointed to an "invalid city" response.
Stations would retain their "historic" names.
Mod note: Split topics from the "new feature - performance issue" thread for clarity.