This would seem to counter “This allows actors that have not been designed to work with each other to communicate, just by sharing the same tuple space.” Alternatively, I don’t see the big difference to just using separate message queues with pattern-based retrieval. In the end, you always have to design who communicates with who in which format.
The Syndicated Actor Model started off (see dissertation) without any notion of object or actor or entity reference at all. Actors inhabited a single dataspace and there was no baked-in addressing. Since then various developments have led to introduction of entity references (like object references in E). Taken together with dataspaces, this gives you several ways of introducing spacelike separation: you can use different message shapes+patterns, like in "classic" Syndicate or like in tuplespaces; you can use entity-references to have multiple dataspaces on the go at once, forcing isolation that way; or some combination of the two.
Absolutely. A message queue with pattern-based retrieval is a hacky way of getting the first two-thirds of a tuplespace. But, like using a database as a message queue, while it kinda sorta works for the most part, the benefits of the model come in when you start to treat it on its own terms rather than via an encoding. Tuplespaces have a little more to them (not a lot, but some) than just pattern-based retrieval, but some of the research work on them has been focused on appropriate fault-recovery strategies, strategies for sharding and distributing the spaces, etc etc.
