Thank you very much for the review @xwu! I'm very glad it seems we addressed points from your original notes 
Noted that we might discuss the AnyActor thing more. It came out of soundness issues if we didn't do that. Once out of holiday break I'll write that up again and perhaps there'd be a better solution (I tried, could not find any - Swift's "actor" is too permissive imho is the problem, but it was done so intentionally to make not-distributed-life easier -- for better or worse...).
Quick ones while I have a moment with laptop in hand on the small points:
One mental shortcut too much there perhaps -- this means that someone can conform to that requirement using a struct AnyDistributedActorSystem: DistributedActorSystem and do the usual erasure dance there, if they wanted existential actor system support.
Oh thanks for spotting that -- this indeed should be (and is in the impl) the specific ActorSystem.
Oh boy 
Opening up the flood-gates I guess... I really am not even a fan of the properties... but it's been requested "enough" that we loosened it up for those specifically...
It is difficult to make many things possible here because it causes things to the potential / possible better mangling and "distributed invocation target" identification schemes... as long as it is just simply named things (methods, properties (basically method without parameters)), it is simple to move to a "don't pass mangled names" identification scheme... I worry a lot about just opening up for subscripts and all kinds of other stuff as it might cause us more complexity and runtime/wire cost in the future... I probably need to revisit and re-articulate this worry a bit more specifically though -- note taken!