Erlang was an inspiration, with its links and monitors. If you squint, the replication-of-state is a generalization of links and monitors from just "lifecycle state" to other kinds of state.
What it gives you beyond the usual actor model is a way to decompose/compose your actor's behaviour to treat each conversation it is engaged in separately. A bit like having a supervision hierarchy internal to each actor.
This includes associating actor-internal state with particular interactions it's having with peers, as well as routing incoming events to conversational components within the actor.
It also allows incremental view maintenance: you can "subscribe" to "published" state from peers, again routing updates in that state to particular conversational components.
And of course it handles partial failure elegantly, by allowing actors to tear down conversational components when a peer crashes. It lets you precisely scope the lifetime of intra-actor state to a given (sub)conversation.
Finally, it's not a single-language thing. It's a polyglot thing. Because it's a very simple model, with a correspondingly simple protocol, it's easy to bring programs written in different languages into the same conceptual actor framework. The biggest Syndicate deployment I've had so far had participating programs written in Racket, JavaScript, Rust and Python all interoperating.
I started down this research line as a result of using Erlang when I was writing the RabbitMQ server. In a lot of ways, AMQP and Erlang were trying to do the same thing; each had great characteristics the other lacked. So now, Syndicated Actors and Dataspaces are a unifying perspective on what makes "messaging middleware" great as well as what makes the Actor model great.
I should also say that of course you can do all this stuff in Erlang alone. Or in any other actor system. But you'll very likely end up greenspunning yourself something very similar to what syndicated actors offer, once your actor system gets beyond a certain complexity level.
(I've also been thinking about implementing syndicated actors as an Erlang behaviour, to allow Erlang actors to peer with other syndicate actors. The process dictionary would be a nice place to put the dataflow variables; and I could abuse monitors to implement the automatic-retraction-on-termination feature...)
