You can substitute the word 'interactivity' with 'statefulness' and it makes the statement more intuitive IMO.

Concurrency + statefulness means you can't have mutability because then you would run the risk of a concurrent update overwriting another. But you can have concurrent read-only state, so long as concurrent writing is not permitted. This is the 'single writer principle' which is a variant of the 'single source of truth principle'. You can't have concurrent writing in this case.

If you have statefulness + mutability then you must do away with concurrency; a different way to avoid the same concurrent overwriting problem mentioned above.

If you have concurrency + mutability, then that's possible if you don't have state... You could have multiple independent, divergent copies of the state but not a single consistent state.

'Statefulness' doesn't make anything clearer.

What exactly are you mutating?

> If you have statefulness + mutability then you must do away with concurrency; a different way to avoid the same concurrent overwriting problem mentioned above.

Last time I checked we had plenty of concurrency primitives allowing for that; you might need to wait few tens or hundreds of nanoseconds for a lock (or few orders more over network), but it works just fine