My observations with the go-to-depot are if a train is waiting at a signal to enter a tile, and the train occupying that tile is then told to goto depot, and it 'jumps' when doing so, then frequently on the client, the waiting train proceeds through the signal, the two trains overlap, and sometime later a checklist mismatch desync is triggered. If I manually reconnect to the server immediately to see its state, I see that waiting train is actually still waiting for the depot bound one to clear. I've not been able to duplicate under controlled circumstances with a graphical server and client both running...
In general, it appears this, and several other issues all have block reservations in common as the desync culprit.
Phantom signal - using the track way removal tool to disconnect a piece of track from an adjacent one containing a signal sometimes results in the signal vanishing from view. It also does not show up as an object when clicking on the tile. Trains proceeding over the spot where the signal was enter a state where they reserve tile by tile rather than to the next signal. Often a save/reload clears this phantom signal. Bulldozing everything on the tile, and rebuilding the track results in the same behaviour returning. Building a signal on the tile is allowed, but it never clears (goes permissive). Deleting the signal does not fix things.
Trains running red signals - once a train is in a tile by tile reservation mode, it seems to ignore all further signals server side - sometimes client side. You can watch it follow a train - it's always one reserved block back in the same signal section. Once it reaches the next station on its schedule, it returns to normal behaviour obeying signals. If the platform at the station is occupied, and it's a terminal station (same way in/out), then it will block the exit and deadlock the system.
Usually you don't see this deadlock client side, instead the train is correctly waiting at the signal. Reconnect to the server, and suddenly there's a train sitting where it's impossible to be except by running a red.
If a train has a path reserved from a signal to the next, and you delete the next signal (bulldoze) before it goes permissive, the train will enter the tile-by-tile mode. Client side after a couple blocks of this tile-by-tile, it reverts to signal-signal reservations. Server side it seems to frequently stay stuck in tile-by-tile, ultimately leading to the deadlock above.
Anything that results in a train jumping and redoing it's reservations is also likely to trigger a desync. Editing schedules, especially editing the line schedule is quite dangerous. If you add a new waypoint, quite often trains change their destination to the waypoint even when they're already beyond it in the schedule. The resultant jump when they turnaround results in behavior much like when they jump due to the goto depot command. Related, it would be nice if vehicles were smarter about line schedule changes so they didn't turn back... it's a pain to have to visit every single convoi in a line, and open its individual schedule to correct the current destination after you add/remove a waypoint... That would minimize jumping too...
