Ok, I am going to have to be very careful here with my response: the word "should" infers two things - a moral obligation, and also it infers future direction. Neither of which are things I can tread into.
However I think it is useful and productive to discuss the functionality that we can add to AsyncSequence (especially since it is part of the Swift open source efforts). We should also outline the both functional and imperative sides of things that would be useful to flesh out the concepts of a set of algorithms that would make asynchronous things that happen more than once; a set of algorithms that are just functional are likely to not have general appeal, likewise for a set of algorithms that are purely focused on imperative code could have some detractors as well. So I think any solutions should be a balanced approach catering to the things that are common tasks that developers face.
I think there are a few examples of categories that are worth talking about:
combinators - things like zip that bring multiple async sequences together
distributors - things that do the reverse of zip, that allow multiple interested parties to deal with an AsyncSequence
composition - things that allow building stuff up (I could imagine things like @resultBuilder could be neat here to bridge that gap of functional versus imperative
value transformation - most of which this type of thing is covered by the similar APIs to Sequence, but there could be others that would be interesting to investigate
ordering transformation - Sequence does not have these since it is not asynchronous so this might be a neat area of discussion
temporal transformation - again this is another area that is missing and would be good to talk about
There are a number of VERY related efforts that are of interest:
Obviously for the temporal transformation category: [Pitch] Clock, Instant, Date, and Duration is a big part. Having a duration type will allow for the concept of throttling or debouncing etc.
For combinators such as zip: Pitching The Start of Variadic Generics is in my experience developing other similar APIs a must-have. Else you are limited to a fixed number of combinators
For general ergonomics SE-0328: Structural opaque result types is I think a very critical proposal because it makes the concept of erasure much easier to reason about (avoiding having perhaps questionable hanging statements like .eraseToAnyPublisher() or the equivalent)