As Kylotan pointed out to me, the term rewinding is ambiguous and can mean looking up some previous state, and going back to a previous state and simulate forward again to the 'present'. So to clarify, to solve the case of simulations becoming divergent you don't need either form of rewinding on the server. You could rewind and forward on the client or you can just send the correct state from the server for clients to snap/interpolate to.

For some type of games you will need to be able to look up a previous state. Having that could make it trivial to add the ability to forward the simulation from that state, which might be a reason to go for that route.

There are a lot of ways to go about this, each with their own costs and benefits. Choosing what's right for you depends on the time you are willing to invest, the complexity you can handle, the type of game you are making and other requirements you might have.

Ok to nail this down, I was doing a lot of research about this topic and didn't find a proper solution. So I designed a mix of both and I share this with you:

1) We use both techniques Rewinding and Correction
2) We mix them in a very clever way

Rewinding has the negative of becoming unfair to other clients if rewinded to far
Prediction can be always wrong if no rewinding is applied.

So both systems have a negative. But we can remove them mostly when mixing them cleverly.

When dealing with such systems you normally have a snapshot interpolation system on the clients to render the world in past for lag compensation. This gives us also other possibilities.

Normally you delay the past for 100ms (depends on your Snapshot rate 100ms delay = 20/s) We can use this 100ms delay.

So we have to set the following rules for our system:

1) If a package arrives and the timestamp is only <50 ms behind we can rewind and resend the state to the clients
2) If a package arrives and the timestamp is > 50ms && < 100ms we can rewind the last state and assume the client is moving since 100ms so we rewind the previous state to have actually moved 50ms and the next is going to be also 50ms moved. Then we resend the previous state
3) If a package arrives and the timestamp is > 100ms we have to correct on the client for the amount Above 100ms. So we combine rule 2 with a correction on the client above 2.
4) The resend states are marked as a resend so they are special states
5) If a client has a action that needs hit detection on the server as an example he sends the stateID with it. If on the server the state was already corrected but as the Client sent the non corrected state we do the collision against the non corrected one to be fair as the other client hasn't received the corrected state.

With these rules we can ensure that our prediction system is 100% correct if delay is <100ms and if we have a delay above 100ms we only have to correct the amount above 100ms. and here we can decide between snapping and interpolation corresponding to amount we are off. Lets say we are only on 110ms delay we could interpolate the last 10ms but if we are on 200ms delay we would snap.

I think the system I created is very well. If you find something that is better of not logic please tell me.

This sounds like it just moves the "on time" deadline backwards by 50 milliseconds?
Why wouldn't you just shift the time for which clients send packets forward by 50 milliseconds, for the same effect?

This sounds like it just moves the "on time" deadline backwards by 50 milliseconds?
Why wouldn't you just shift the time for which clients send packets forward by 50 milliseconds, for the same effect?

I need an example timeline where you show what happens on the client and server as I don't exactly know what you mean?

You are saying that you re-simulate the server based on data received by the client up to 50 ms late.

How is this different from just saying "the deadline to simulate time X is moved down by 50 ms?"

What you end up doing here is either waiting to send an update to other players until the deadline has passed (so, delay updates by 50 ms,) OR send updates that you know are wrong, and you reserve the right to change the outcome later (essentially, send extrapolated values.)

Why wouldn't you pick one (delay updates more, or send extrapolated values,) and just make that the deadline? It seems like your analysis of "separate cases" just muddies the waters.