You're right, Using `receiveAsFlow` will produce a hot Flow but it is a regular `Flow` not a `SharedFlow` which isn't the same, this flow will be

consumed by only ONE collector/subscriber, the basic idea behind `SharedFlow` is to be shared between multiple subscribers. if you looked again at @Micheal_Forgues article you will see the 1st requirement in the Requirements section is:

- "New events cannot overwrite unobserved events"

`SharedFlow` violates this rule/requirement. Why??

Consider this scenario:

you have a `SharedFlow` of 1 replay parameter and `BufferOverflow.DROP_OLDEST` policy and you have 3 Unobserved events, the oldest one of the 3 events will simply get dropped and the consumer will never know about it. Moreover, the 2 newer events overwritted/overlapped our first event. So, again this violated out rule we declared above

Hence, we can deduce `SharedFlow` isn't suitable here, but why Buffered channels in particular?

if you looked again at the article, you will see the following quote:

"channels also have their application use-cases. Channels are used to handle events that must be processed exactly once. This happens in a design with a type of event that usually has a single subscriber, but intermittently (at startup or during some kind of reconfiguration) there are no subscribers at all, and there is a requirement that all posted events must be retained until a subscriber appears."

which exactly adheres to our rules/requirements.

As a TL;DR:

he implemented his requirements using channels bacause it is the best candidate here to do this use case and he exposed a `Flow` for consumers to ease consuming and because he guarantees that this flow will only be consumed by a single subscriber