I don’t think that’s necessary or desirable to add a group concept like this.
The need itself is valid and real. How it can be addressed is by special executors, specifically: each actor is bound to an executor, there can be various executors. We can build “SingleThreadExecutor” or something like this, and pass it to multiple actors on construction — it is then known that they all share the same “real” thread and it can be checked on dispatch because recipient.executor.shouldEnqueueOrExecuteDirectly(from: self.executor) (silly pseudo code, you get the idea).
It’s an extension of the idea of: if we’re calling an async function on “the same actor as I am” there’s no need to enqueue but we can keep running that function — but extending it to awareness of “do I need to hop or not”.
Such mechanism would also enable Swift NIO to express itself in form of actors I believe — since there are many ChannelHandlers which may want to be actors, but they often invoke eachother but they are all guaratneed to be on the same event loop (which is exactly 1 thread).
So grouping actors together based on how they execute I would not recommend, we should rather attempt to solve this by executor semantics I beleive.
--
Small side-note: it is not unheard of to break the "actor can run anywhere" illusion and actually peek into them for optimization's sake, so I would not be nervous about such things.