The only new object types are signalboxes; but I do not think that this is an object types issue, as client and server stay in sync even on a dense map (with lots of signalboxes) for many hours (overnight) when both client and server are on the same computer connecting via the loopback interface.
I do not think that multi-threading is an issue, as the desync occurs even when the server is single threaded, but does not occur when both client and server (on the loopback interface locally) are multi-threaded, nor when both local client and remote server are multi-threaded.
This is not the old electrification issue, since this occurs even when there are no power lines or substations on the map, and does not occur when there are power lines and substations on the map when both client and server are connected by the loopback interface locally.
It is also not an interaction issue (i.e. one related to not properly sending/receiving commands), as the desync occurs when idle without any commands being sent by any player.
The Bridgewater-Brunel server runs Linux whereas my computer at home runs Windows - I wonder whether this might be relevant. This was an issue once many years ago, when the problem transpired to be that Windows and Linux builds dealt with imprecision in floating point arithmetic differently, but all floating point in running code was abandoned after that, so it is hard to see what the problem might be.
Can anyone try connecting with a Linux machine to see whether that remains stable? I might try to connect using my Linux NUC that I use in work, but I think that the only cable that I can use to connect it to my monitors at home may have failed, so this may not be possible.
Edit: I have been able to get my NUC working (the HDMI cable issue seems to be intermittent), and confirm that I can connect to both the Bridgewater-Brunel and the server.exp.simutrans.com servers without desyncs from a Linux build of the latest devel-new-2 branch, whereas I cannot connect stably to either from a Windows build. This is very odd: I cannot think of anything other than floating point arithmetic, which has been eliminated, which might cause this. Has anyone any ideas of what might run differently in Linux and Windows?
Edit 2: Running it through Dr. Memory, I get the following suspicious entry (but it is odd, as no actual crash is encountered in the game):
Error #1: UNADDRESSABLE ACCESS: reading 0x4d6f8d40-0x4d6f8d44 4 byte(s)
# 0 _longest_match [F:\Develop\vs140\build\zlib-1.2.8\contrib\masmx86\match686.asm:375]
# 1 inflateUndermine
# 2 deflate
# 3 gzungetc
# 4 gzwrite
# 5 loadsave_t::flush_buffer [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\dataobj\loadsave.cc:605]
# 6 loadsave_thread [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\dataobj\loadsave.cc:63]
# 7 pthreadVCE2.dll!pthread_setcanceltype +0x4bce (0x71445eef <pthreadVCE2.dll+0x5eef>)
# 8 MSVCR100.dll!endthreadex +0x39 (0x77f4c6de <MSVCR100.dll+0x5c6de>)
# 9 MSVCR100.dll!endthreadex +0xe3 (0x77f4c788 <MSVCR100.dll+0x5c788>)
#10 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x7517336a <KERNEL32.dll+0x1336a>)
Note: @0:10:00.187 in thread 4556
Note: refers to 0 bytes(s) beyond last valid byte in prior malloc
Note: prev lower malloc: 0x4d6e8d40-0x4d6f8d40 here:
Note: # 0 replace_malloc [d:\drmemory_package\common\alloc_replace.c:2292]
Note: # 1 zcalloc
Note: # 2 deflateInit2_
Note: # 3 gzungetc
Note: # 4 gzwrite
Note: # 5 loadsave_t::write [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\dataobj\loadsave.cc:587]
Note: # 6 loadsave_t::wr_open [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\dataobj\loadsave.cc:413]
Note: # 7 karte_t::save [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:6319]
Note: # 8 karte_t::interactive [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simworld.cc:8765]
Note: # 9 simu_main [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simmain.cc:1363]
Note: #10 sysmain [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simsys.cc:805]
Note: #11 WinMain [c:\users\james\documents\development\simutrans\simutrans-experimental-sources\simsys_w.cc:968]
Note: instruction: xor 0x04(%edx,%edi,1) %eax -> %eax