Being in single threaded environment is extremely taxing. Right now the simulation runs at 30Hz, but if it were to increase to 60Hz then we will have even less time budget to finish certain computation per update cycle. I don‘t understand how the roadmap envisions us to build AAA games / simulations in a few years with such a constraint. Sometimes you have to perform some computational heavy and long running task, which may not be interrupted through suspension. In the current environment it would imply that all other work will be blocked as soon as we start with such computation.
Let‘s assume that verse is not in a single threaded environment. That would make my point from the original post clear that the 4th operation of reading the variable in both tasks could result in a value that is different from what that task just tried to assigned it to, as the other task could have overridden it. In a multi-threaded world, Verse‘ shared mutable states would become unsafe. Sure there are transactions that would do the locking for us, but that would still not prevent us from race conditions.
The problem I have with all this, is that I seek for official clarification so I can safely adapt my expected behavior for Verse‘ concurrency model.