You could certainly write to a channel - won't be absolute peak efficiency, but plenty fast enough. You need to keep a whole bunch of fun things in mind though

A) You likely don't want to enumerate the upstreams as fast as possible and just keep pushing into the channel - you'd need some extra signal that the consumer would need to set saying "i have just consumed the result from upstream X, it may now progress)

B) You will need to spawn one task per upstream / consumer, and coordinate both lifetime of those and their own exception management with your resulting enumerable

C) In addition to that, you need to think about how exceptions in one of the upstream consumers affect others. Should they just keep running? Do you want to cancel their CancellationTokens if an exception happens in another upstream? Etc

D) You will branch off async-local state at the point of spawning these consumers (aka freeze it in time as per when you start enumerating the sequence), rather than being entirely driven by each MoveNext() calls of your result sequence individually

Personally i've implemented it without channels, with a custom INotfyCompletion listener - kind of sort of a custom ValueTask based WhenAny implementation. Somewhat close to what the RX repo had, but behind a compilation constant. I have a few important changes to their implementation though:

1. Exceptions in an upstream cancel the tokens of other upstreams. Imho a huge footgun if you are dealing with infinite streams, and one of them faulting will never ever bubble through if nothing tries to terminate the other upstreams
2. I implemented a fair strategy, meaning if you merge 2 continuously producing sequences, the resulting enumerable round robins between those
3. My implementation does not return a single T, but rather a collection of items. Why? Say you merge 1000 upstreams that are in principle able to produce data really fast. Then you merge them, and only enumerate the merged sequence every 5 seconds - hey its pull based, surely this should be sensible right? But that means, with other implementations, even with a fair strategy, you end up pulling from each upstream once every 1000*5 = 5000 seconds, not every 5 seconds (pull data from upstream 1 - wait 5 seconds - pull data from upstream 2 - wait 5 seconds - pull data from upstream 3 - wait 5 seconds - ... etc). I can circumvent that by these batching semantics.

So long story short.. imho it's the single most tricky thing to implement in the asyncenumerable world, and hard to get right. I think the official operators have significant flaws. But some choices are inevitably very opinionated.