Thanks for the early replies and feedback everyone! I'll go "topic by topic":
Typed throws
On a personal note, and coming from years of work both with checked exceptions as well as actor runtimes, I really don't really think typed throws are as great as forums threads often make them out to be. They look nice in small examples, but in long running, evolving projects, they're more of a trap than help to be honest IMHO since they become part of the API and can never change; while error conditions or underlying transports and implementations do change all the time.
Ok, but typed-errors rant aside: you are correct, if Swift had typed errors this indeed would be possible to enforce that errors thrown by distributed functions must satisfy the Codable (or similar) requirement.
Do note however that signatures would become a union of YourError | ActorTransportError and be may be somewhat annoying to deal with...
Having that said, there are currently no plans for typed throws in Swift so this design cannot assume them.
Codable
Being an avid protocol buffers user for many years myself... we do have to realize though that the two are at odds here -- since both protocols (or someday maybe "service definitions") and protobufs Interface Definition Language serve the same purpose: to be the source of truth for the types involved. We are interested in making Swift protocols be the interface definitions, rather than using external languages to do so.
Related note: The reason for SwiftProtobuf not adopting Codable isn't just performance, it is because the entire model of working with those types is completely different - they're IDL driven and have their own quirks.
This is what the future direction Future Direction: Ability to customize parameter/return type requirements is all about. It's a relatively simple future feature and it may even just happen during the initial work on this feature.
It would enable specifying any other type requirement, other than Codable that parameters and returns are checked against. The example uses a "SuperSafe" enum of trusted values, but equally well one could imagine using ProtobufMessage there if one really wanted to.
ActorIdentities with multiple replicas
To answer your question about "actor is a service, has multiple replicas" -- they'd have different identities, because an identity must uniquely identity a specific actor.
Think of ActorIdentity similar to ObjectIdentifier however that can persist over time and process boundaries. This matters for example, a "long lived" and "well known" distributed actors which can be resolved a well-known identity such as /virtual/game/lobby and the system ensures there is always one such actor and it can always be resolved, regardless where it is physically located.
Typically though actor identities are more specific, for example following URL-ish patterns like this: sact://127.0.0.1:8888/user/worker#123545 where the last bit is the unique identity of it.
How specifically identities are used it up to the transports though -- some may choose to just use an integer (process IDs perhaps?) and perform mapping of those integers to actual instances.
This is why the identity is a protocol.
Polyglot communication
So while it is absolutely possible: you can easily implement a _remote function in a way that a remote other-language process may understand, this is not a goal of this work. We are aiming for simple and native feeling Swift actor systems that inter-operate the best with each-other.
In a server world it is best to think about this as best used within a single clustered service. You wouldn't really mix languages within the same system; going across languages can of course continue to be done with gRPC and HTTP and other tools. A similar approach has been taken by Akka and other actor runtimes in the past.
In a multi process world, we are interested in making xpc services and other cross process work on Apple platforms "feel great". Think how NSXPC works great in objective-c but feels pretty weird when used with Swift; this is a similar situation here, we intend to provide a solution that feels best for Swift, and it may be accessible to other languages, but it is not a primary goal of this work.