I think I must be missing a detail, because it feels to me like your spooky example of peeking over the cubicle wall is in direct conflict with the idea that nobody can modify an object's mental state except by passing objects to it.

If you're really only allowed to communicate by passing messages, then, to me, that would imply that there's some sort of "no peeking" rule.

Say I send you a mutable object as an argument of a message / method-call while holding on to that same object in some variable as well. You modify that object without telling me. Does that mean you are spookily communicating with me?

I would say no because you are not communicating with me at all. I am unaware that you have modified the object.

I can ask that object about its state and that way detect that somebody has changed it. But how can I ask it about its state? Only by sending it a message/calling its method, IF I am using an "Object-Oriented Language".

There is nothing spooky about multiple observers having access to the same shared mutable object, is there? They can still only extract information from it by - sending a message - in an Alan Kayesque Object Oriented language.

But in a hybrid language like JavaScript where I can directly read and write and even delete fields of an object it is spooky, this value was just here and now it is no longer and I don't know why because somebody else somewhere deleted that field.

Gotcha. I think, then, that the devil is in the details. That Erlang ets module I mentioned elsewhere does something like this, where it creates an entity that acts as a shared mutable data store, but communication with it still happens by message passing, so you still get certain guarantees. Notably, if you query it for some information and then get your response back, that response's contents aren't going to change on you. So the behavior's really more like querying a database than getting a pointer to a mutable data structure.

There's maybe a "letter of the law vs spirit of the law" thing going on here, too. Having an object that just implements an array feels like it's violating the basic idea, even if you are technically only communicating with it by passing messages. I'm pretty sure the original vision was that objects would represent interesting entities from the business domain and not just be heavyweight analogues for basic data structures.