[AsyncAlgorithms] FlatMapLatest algorithm

[vanvoorden (Rick van Voorden)]

@Philippe_Hausler

The interface is available on all AsyncSequence types where both the base and inner sequences are Sendable along with two disfavored refinements to account for variations of typed throws signatures:

extension AsyncSequence where Self: Sendable {
  public func flatMapLatest<T: AsyncSequence & Sendable>(
    _ transform: @escaping @Sendable (Element) -> T
  ) -> some AsyncSequence<T.Element, T.Failure> & Sendable where T.Failure == Failure, T.Element: Sendable, Element: Sendable

  @_disfavoredOverload
  public func flatMapLatest<T: AsyncSequence & Sendable>(
    _ transform: @escaping @Sendable (Element) -> T
  ) -> some AsyncSequence<T.Element, Failure> & Sendable where T.Failure == Never, T.Element: Sendable, Element: Sendable

  @_disfavoredOverload
  public func flatMapLatest<T: AsyncSequence & Sendable>(
    _ transform: @escaping @Sendable (Element) -> T
  ) -> some AsyncSequence<T.Element, T.Failure> & Sendable where Failure == Never, T.Element: Sendable, Element: Sendable
}

I'm wondering why we should prefer an opaque some return value here on these. From what I can tell so far Standard Library APIs on AsyncSequence like map and compactMap return public concrete types: AsyncMapSequence and AsyncCompactMapSequence. And AsyncAlgorithms APIs on AsyncSequence like zip and combineLatest also return public types: AsyncZip2Sequence and AsyncCombineLatest3Sequence.

I'm a fan of opaque return values and don't mean to block that… but I'm wondering if there was a little more explanation why for this specific case we might be blocked on returning a new public type.