Well, on the software development tangent: I've seen multiple people working on the same source code together and it tends to work pretty well. I think the buzzword is 'pair programming.' Buzwords aside, though, if the people are working together instead of off by themselves, it seems to work fine.
Yes, definitely. Real world software projects require team development. "Pair programming" or "peer programming" is an extreme form of collaboration in this context. That will work, because they sit next to each other and feedback is immediate. In all other cases people should work on their own task with clear and compact interfaces. Keeps interdependencies to the necessary minimum, even with a lot of abstraction layers and intensively reused class libraries and frameworks. But that's what the repository tools are made for.
However, I don't know that creating / editing a route is directly compatible to editing source code - while there are some logical dependencies (track and signalling, perhaps), much of the work is merely visual.
You don't want someone else to place buildings or flora when you are still landscaping.
The off-the shelf repositories I've seen don't seem to do a very good job of merging binary files
The more modern ones have no problems here. They are nearly as good with binaries as with text. Actually I'm using the SVN algorithm for binaries to distribute TransDEM patches. Nonetheless, changing the Trainz route file formats from binary to XML would be a step forward, making it much more interesting for all sorts of helper tools.
I haven't used Zusi, so this might make sense. Having the scenery match across interfaces might be a little challenging if the modules only get merged at runtime, though?
It was one of these things learned from Zusi 2. Proper routes need proper teamwork. (Proper routes: Suitable for professional loco driver training and also appealing to the eye for realism - depending on how much the customer is willing to pay, of course). The modules have clearly defined matching borders (based on UTM coords). There is no baseboard system in Zusi, even if the renderer internally uses 500m and 1000m rasters. Break modules anywhere, usually in the middle between stations, and at any angle. Due to DEM technology, modules will match as they do in Trainz. To set up signalling, adjacent modules will be loaded temporarily. Finding paths (interlocking) is a largely automated process. All these invisible connections between modules are saved with the individual route module. When creating the working time table, the modules are analysed for their overlapping features and the cross-module signalling features get deployed. Finally, during runtime, all comes together and you normally won't notice any module borders, neither visually, nor railway operation-wise.
This modular concept gives maximum flexibility for team development, even if a typical workflow pattern has emerged. In that pattern it alls starts with research, acquiring maps, photos, track diagrams, DEMs, etc. Track laying is next. Zusi 3 has a separate CAD-like tool for that. After that move to 3D editing what we would call the classic route editor. You have typically more than one person active here. But it goes in stages. They have specialists for signalling, catenary, landscaping, buildings, road infrastructure or vegetation, but usually only one developer is working on one module at a time. Finally time table creation, putting the modules together and running trains over them. Another specialist here. All files including resources, are kept in a central repository which has been migrated to SVN a few years ago. It used to be CVS in the beginning. In those times it helped that Zusi 3 files are all XML, because CVS was weak on binary formats. Some of the present day Zusi 3 tools have built-in SVN client support.
Overall, an excellent architecture for route building in a team. Repository technology is the very same as in professional software development development and it offers all these off-the-shelf features: distribution, backup, branching. No complex client/server solution, just applying IT standards. Some might argue, handling SVN would be too difficult for people without sufficient IT background. Be assured, that's not true.
Disadvantage for a commercial company: This architecture does not generate revenue.
(And, since the SVN server is privately operated, no big brother data mining takes place.)
But once again, without proper management, the Zusi route projects would have failed. Everybody doing what he likes will get the project nowhere, even if the current "NEXT" marketing letter suggests just that. But there is a difference between Trainz and Zusi. Trainz takes a much more relaxed approach to route building, since the end result is not the primary goal. The purpose of Surveyor is that the user has fun.