Author here. One of the cool things about the property we're using here---disentanglement---is that it specifically allows for shared data, under only mild restrictions. This allows us, for example, to implement fast libraries which utilize shared mutable state for efficiency under the hood. A good example is our parallel arrays library (https://github.com/shwestrick/sml-parseq), which is "purely functional" in terms of its interface, but not its implementation.
It's helpful here to distinguish parallelism from concurrency. Disentanglement naturally emerges in data-race-free parallel programs, which have no concurrency. But certainly, you bring up a good point for programs that are highly concurrent in addition to being highly parallel. There's lots of work already on concurrent functional programming, for example CML (https://en.wikipedia.org/wiki/Concurrent_ML), and we think these ideas could be adapted to work with disentanglement really well.
It's helpful here to distinguish parallelism from concurrency. Disentanglement naturally emerges in data-race-free parallel programs, which have no concurrency. But certainly, you bring up a good point for programs that are highly concurrent in addition to being highly parallel. There's lots of work already on concurrent functional programming, for example CML (https://en.wikipedia.org/wiki/Concurrent_ML), and we think these ideas could be adapted to work with disentanglement really well.