As for the existing types we "just" need to land the SE-0406 proposal which will do some of the cleanup requested here.
As for an actual good way forward: fan-out needs to be explicit and behaviors configurable.
We cannot pick one behavior and say it's "the one", as such concrete streams should always be single-subscriber (this is the same idea as with when we designed reactive streams which are the "base" stream/subscription/sequence semantics).
How does that look like in practice? Explicit operators which define the various semantics, like:
- cancellation:
- cancel when one cancels
- cancel when all cancel
- etc
- buffering / replay / live:
- buffer and replay to all subscribers
- broadcast from current element to all subscribers
- round robin elements to active subscribers" behaviors
- when elements are emitted
- when completion is signaled
In practice this then creates a number of operators, some with "options". In my previous life, working on Akka streams we came up with a bunch of operators like "wireTap" "alsoTo", "alsoToAll" etc. List here: Operators • Akka Documentation
And most importantly, every operator explicitly documents its behavior in a "the same operator has the same table format of information", like this:
I think that we should follow a similar pattern here, and consistently use the same "template" (that we need to come up with) for an operators semantics, and document every single operator, and especially fan-out operators in this tyle.
Of course I don't mean to imply we just use the same template or specific reactive streams semantics, but a general "template" for understanding the behavior of streams and consistently documenting them all is something we could definitely make use of! It'd have to focus on Swift and async/await/AsyncSequence specific wording and semantics etc. I think this would definitely help using and understanding async streams in Swift 
And as we'd perhaps manage to revive the broadcast() proposal (?), that'd be a great one to put this to practice -- along with the SE-0406 work during which we could cleanup some docs and behaviors