Even filling a cabinet could be a function that takes a cabinet and returns a new cabinet, but point taken;)
When we talk about something shared, we also identify something and refer to it. Mutability would mean that we change something without changing it's identity. And immutability would mean that we also change the identity. But how in the real world we know that something is the same or changed? Tastes like chicken - gotta be chicken;) I think in real world, when we expect change we use containers. We give it an identity and expect contents to change, but not the containers itself. That looks like an object with data inside;) But wait a minute! Object is intended to be an instance of a class. It's like having a blueprint (class) and several things (object) built from this blueprint. That looks like we are manufacturing containers to store something, but is this what we are intended to have in the first place? We might have wanted something unique with identity to store our changing data. I think the problem is that data should stay data, and not be a part of an object. I've seen Java objects becoming so big that they look more like a separate subprogram with it's own data and functions. Now imagine this class has a superclass and a child class. How crooked is that?;) One program become a parent of another program, which itself can have children. That escalated quickly.
I gather it would be more reasonable to separate namespaces from classes like Clojure does. Who in sane mind would want to put data in a namespace? That makes no sense, so that data in objects be;)
After clojure.spec it became clear to me how we really reason about data. We state our expectations. It's more verbose than types, but what is type? It's name that is attached to data. Name doesn't tell much, huh? In this respect spec tells more about the data then a type. It's a less strict contract that is closer to what we have in real life and that's amazing.
Rock on! I'm glad you get what I'm talking about.