We worked with the core team on staging these proposals and arrived on this order. The first pitch contained "everything" and was far too much to take in for reviewers. I don't think we can propose just "the programming model" without discussing actual syntax to be honest.
I do feel however this proposal is self contained, and we're actually not discussing anything it focuses on which is a bit disappointing... There is a lot of details about protocol conformances and how distributed isolation affects those we could dig into here, none of those really relate to runtime and the split of runtime and compile time checks does make sense to me to be honest. This proposal enables any kind of programming model and runtime to be proposed formally next after all.
Continuing with comments regarding runtime aspects though.
This need not be part of the language per se and is to be implemented in libraries, which is why it is not going to be covered here (and definitely not in the isolation proposal for what it's worth).
I explain how this is implemented in the cluster announcement: [Video] Distributed Actors announced at Scale by the Bay and you're free to review the implementation in the cluster reference actor system: https://github.com/apple/swift-distributed-actors/blob/main/Sources/DistributedActors/LifecycleMonitoring/LifecycleWatch.swift and how it uses SWIM for the monitoring nodes.
This isn't a "receive block", it's just a local method called like that.
There is no "receive block/loop" being proposed in our model. (We had this for a long time, while we didn't have any language support for making the calls, and decided to simplify the model and offer distributed methods).
This isn't unheard of, exposing a simple "method based" programming model is what made Orleans successful.
Again, this is jumping far ahead and not related to actor isolation... We can take this to the Distributed Actors - Swift Forums forums category if you want to discuss streams and distributed actors.
The short answer is: yes, this is doable and I've built just that in my "previous life", having worked on reactive streams which combine/async-sequence is based on conceptually, as well as akka-streams. See here for the documentation of the feature I implemented over there: StreamRefs - Reactive Streams over the network • Akka Documentation - a stream ref is in Akka terms "send a (reactive stream) endpoint to other distributed actor". In Swift it'd probably look a bit simpler, since we have distributed methods and "just" AsyncSequence, but the concept remains the same.
Again, this is something I'm keenly aware of, but we can survive just fine enough without right now.
The concept of "send" also known as "don't wait" sending messages to actors is coming up very frequently in various proposals, even on local actors. It is another future direction to express "oneway" or "send" things for distributed actors, but again, this does not matter for the isolation aspect of the design.