@Latty points out a very valid point that this is a concurrency bug. However, you can recover it in the same way that other concurrency system use optimistic co

@Latty points out a very valid point that this is a concurrency bug. However, you can recover it in the same way that other concurrency system use optimistic concurrency (e.g. most STM implementations). You have a `numberOfOperations` field in your model that is incremented every time a message is processed and then check that your incoming new model has a `numberOfOperations` value that is exactly one larger than the current value. If not you then fire off a `Cmd` asking for a recomputation of the original message. However, that can get pretty hairy pretty quickly (since you may not have a nice way of asking for recomputation) so I'm not sure if it ends up working out in the end.