I don't know that area of the code, but the patch essentially avoids using the per-client NextControl facility if the network mode isn't async. If I'm not mistaken, async means that the host decides in which tick a control sent by a client gets executed, instead of waiting for all controls of every client before executing a tick. Assuming the patch does fix something: Apparently the old code was written with the assumption that getNextControl and SetNextControl would do appropriate things even in non-async mode, but was mistaken. Which makes me wonder whether there are other places with this problem, and whether getNextControl and SetNextControl shouldn't be fixed instead. And whether the patched code works with control rates of less than once every tick.

I'd comment in the bugtracker, but it won't let me log in. (I suspect mantis discriminates against Umlauts.)

As far as I'm concerned, the right fix would be to set the next control tick correctly in the first place. See for example here:

https://git.openclonk.org/openclonk.git/blob/HEAD:/src/network/C4GameControlNetwork.cpp#l315

For runtime join, this should probably be "::Control.ControlTick+1", because the client will only contribute to the next tick? Must be careful though, because this might be inconsistent with the client's view. After all, it clearly produced control for this tick - but maybe didn't execute it itself, leading to the desync? Not sure. Plus if I remember correctly just this change would not work with a "normal" game start.