Here is a proof-of-concept patch for double diagonal tracks. It somewhat works: I can build, route/reserve through, and successfully drive on such track segments. The building and routing code was quite straight-forward to modify.
The reservations/driving, however, got rather tricky because in order to select correct weg on a doubled diagonal ground one needs to know either arrival or exit ribi (one of the tile boundary crossing ribis, not the actual driving direction) for the tile which seems to not be available so I had to record it to vehikle.
To me the approach looks reasonable from performance point of view given limited set of expensive looking changes but I'm hardly an expert on this area. Please comment, if you have some concerns.
It is unclear to me if the second weg is needed for something else than crossings which are not possible with a diagonal track in the first place.
What is not working for doubled tracks (or at least likely not working):
- Signals (needs UI extensions to disambiguate doubles from each other during building, hopefully the signals backend code works out right away after UI has ability to build them but I've not evaluated the code yet at all so something unforeseen might show up)
- Waypoints (well, they likely work somewhat but not precisely enough, would require both UI extensions and extented koord3d type for a limited subset of koord3d users)
- Save/Load when a train is on such a tile
- All building that continues from a doubled track (UI extensions needed)
- Track building preview does not display double diagonals but ribi_t::alle instead, just build regardless
- Some conditions with get_weg calls won't get the right weg because I've not figured out how that part of code should disambiguate the wegs, marked with FIXME
- I seem to have managed to break building those annoying parallel ribi_t::alle entirely even though it wasn't my intention :-)
- If something else than trains break, rest assured, I didn't test with anything else
One other open issue is with maintenance cost (no implemented yet though as builder part is currently unimplemented except trivial ability to create double tracks). I think there will be rather inconsistent behavior if a doubled track is converted to ribi_t::alle track by building the link as the maintenance will decrease! I'd rather like to have maintenance cost per ribi to avoid it but implementing that would be another project in itself and would likely require changing the maintenance costs in paks to keep them balanced.
ps. Since my previous post button press didn't do anything, I'm trying now without attachments first. So it's not missing by accident.