Thanks for the review @Joannis_Orlandos!
Yup, that is covered by the current design. Codable is supported, and equally we can support any other serialization mechanism. Codable may not be the best thing for every scenario, but we're very aware many Swift developers are very familiar with it, and its ease of use in Swift is very valuable 
I suspect most implementations will lean on Codable, unless they have specific performance, serialization format or performance requirements it is not meeting today. To that end, we're also interested in improving Codable and the future of Serialization in Swift (though we've been a bit slow to pick up the topic, see thread from a while back: Serialization in Swift).
Right yeah, thanks for chiming in to confirm this aspect of the "implicit" counter-proposal.
Yes, API evolution is tremendously important but I didn't want to dive into it during this proposal which focused only on isolation aspects. We will keep working on this aspect of distributed actors and more features are to be expected to solve this piece more and more in the future.
You may enjoy reading about one aspect of API (and ABI) evolution features we're interested in adding here that I posted in the "proposal #2" that covers the runtime aspects of the distributed actor system: Distributed Actor Runtime: Stable names and more API evolution features. Feel free to use this pitch thread [Pitch] Distributed Actor Runtime to discuss this aspect of the design more
There also exists some prior art with specific versions attached to distributed actors in Orleans (Grain Interface Versioning | Microsoft Orleans Documentation) though this mechanism may end up being hard to implement in the "general" sense in the language (it heavily relies on EXACTLY knowing what the exact cluster implementation does). But I'd be interested in exploring this direction as well.
I understand the request, but again, this isn't something for the current review about actor isolation.
I can let on a sneak peak that we're interested in annotating things with some form of "this func needs some permission" but this isn't really designed... I would want this to not be a distributed actor specific feature but only a way to annotate functions and for their invocation to check (authorize) based a value in task local storage. We haven't designed this yet, and not sure when we will, but it definitely is high on the list of wanted features.
To clarify, because "state transfer" is a bit of a too general term.
The language feature distributed actors does not "magically move this alive actor to another instance, along with its state" without some external mechanisms. A lot of this is achievable with protocols and libraries that operate on distributed actors. You're right that such "sharding" / "balancing" is a killer feature of such runtimes, but it is solved at the library level as it can vary wildly how this is achieved. If you're curious to read up how other runtimes do this, the keywords are "Akka cluster sharding and persistence" and "Orleans Stateful Grains".
The language design here should enable stepping up and implementing such things in libraries in Swift
It's exactly the same really
Since you're implementing that actor's logic... feel free to invoke some db.persist(state) after mutating it. You can also restore such state during an asynchronous initializer even (init(...) { self.state = db.load(State.self, for: self.id).
There's some exciting framework (just in open source packages really ) opportunities to work on these things, but we won't be proposing such into the language I think as I don't think we really need anything special here