>Mutable state is always a problem, but it's a bigger problem when there are less constraints on when it can mutate.

A very long-time project I’m idly working on with my life-long colleague addresses this issue. It is real, as are all race conditions and threading issues. But it doesn’t have to be solved at the language level.

One of solutions we proposed to ourselves was that an object storage should manage shared access conflicts. You may see it in Redux and other stores that serve a “frontend framework backend layer” duty today. Even with explicit async, you will always have some high-level races that must be dealt with. And these do exactly that.

The basic idea is that local state is strictly local and not a subject of parallel mutation, and shared state is shared via internally locking/serializing controller who knows better how to mutate, merge or throw. It doesn’t push the problem down the code or execution model, since it’s what’s it for.

Sounds like you'd benefit from reading Mark's dissertation. Not that he solved the problem but he did try a lot of candidate approaches, discuss them with others, and comprehensively review the existing literature; and he reports on several years of trying things similar to what you're thinking of.

That isn't a "normative" statement about better, but a "positive" statement about a trade-off of expressive power versus rigor. A bit of mathematical intuition suggests that formally asynchronous approaches tend to be less powerful and hence more rigorous. But if your spec is still in the prototype phase, taking on a lot of expressiveness and permission with respect to your domain model is desirable because it gets you an end-to-end solution sooner.

What is good is not "on time" or "robust", but "on time and robust". Necessary and sufficients.

Yeah, that's why I said “produces more reliable software” rather than “is better”. In this case what you're buying with the flakiness is more a matter of performance than of expressiveness, but everything is intertwingled.