Imagine a webservice that reads a `.cfg` file at startup. The configuration is readonly after startup and contains a `JsonNode` part. Can you send an "isolated" configuration to your threads? No, it's shared. You can send a copy, sure. But that is not as convenient and it fails to work when you have lots of data (graphic resources? large language models?). And even if the data is isolated maybe it contains a `ref` to a configuration section that you want to share? So it's "partially isolated" where the isolated parts are written to and the non-isolated parts are only read from.
All these scenarios suddenly start to work with `mm:atomicArc` and are somewhat painful with `mm:arc/orc`. But with `atomicArc` you don't know if you introduced cycles, so people request tooling support to find cycles. Fair enough, but with `sharedOrc` avoiding cycles becomes a **performance improvement** rather than a memory leak **bugfix**.
