I've been thinking about this more, and I realized that the problem for me is that @DistributedProtocol is the wrong name. Everything about the design feels right, but the name doesn't reflect what it's doing.
The language already has "distributed" protocols. They're protocols that refine DistributedActor and have distributed functions in them. Something like this (from the proposal) is already a "distributed protocol":
protocol DistributedAsyncSequence<Element>: DistributedActor
where ActorSystem: DistributedActorSystem<any Codable> {
associatedtype Element: Sendable & Codable
distributed func exampleNextElement() async throws -> Element? { ... }
}
and distributed actor types can conform to it. The language handles distributed actor isolation as part of its semantics, and provides detail to the runtime to manage the distributed actor.
Adding @DistributedProtocol to this protocol isn't making it a distributed protocol, because it already was one. The attribute is creating the client stub type that lets you get a remote instance of a DistributedAsyncSequence without having any access to that concrete type. That's what this macro name needs to capture---the extra functionality you get for adding the attribute. Perhaps something like @RemoteStubs or @ClientStubs or @RemoteClient would capture what it's doing.
Doug