Thanks. We'll consider leaving it out there for longer. What is your suggested timeline? Is having it in a deprecated state for, say, a year enough?

Speaking for me personally: I don't know, that massively depends both on how my life and how the coroutines library develop.
Of course, more time is always better.

But still, what is the reasoning behind this? Why not leave a low-level API in place? Especially considering that what is intended to replace BroadcastChannels is way less mature then those.

Everytime one of these things get removed it breaks projects and libraries.
Also, if this gets removed after many years of its existence, how can I be sure that sharedFlow is not going to be altered in a breaking way soon after again?

What should my strategy be on deciding what to use from the Kotlin STDlibs and what not when I want my programs to be running in five or ten years without having to refactor it with every major release?

There is always a tradeoff. The more code a library has, the harder it is to maintain and to expand. We need to run all the tests for it, we need to maintain the code to make sure it works with all the latest versions of Kotlin, etc.

BroadcastChannel in particular, is extremely problematic because it extends a Channel interface, which is a crucial core interface of a coroutines library and we have future plans to evolve it to allow for a much more efficient/performant implementation of various channels. BroadcastChannels, when they are still in the library, pose a considerable hindrance to those future plans.

I am personally not affected by the deprecation and would prefer faster pace of development of new features vs keeping deprecated.
However, just to be fair I want to point out that migration from channels to SharedFlow might be not trivial since they are semantically not the same thing.

The big elephant in the room of SharedFlow design is error handling. BroadcastChannel design and similar primitives in Rx propagate errors from upstream to downstream.

Channels can be closed and can fail. SharedFlow never completes.

Quoting @elizarov from here:

@pacher We are considering the option of providing a ready-to-use wrapper and operators to materialize/dematerialize completion and errors for sharing so that you don't have to write them yourself. The core design presented here is mostly aimed at sharing never-ending event flows.

So basically if you remove Broadcast Channels now, there will be nothing for sharing of limited-sizes flows. Also nothing for the case of replicating the flow and where one wants to propagate an error.

Everybody migrating to SharedFlow will have to at least implement materialize/dematerialize pair by him(her)self.
I remember I tried and there were couple of gotchas, but unfortunately I don't remember the details.

BroadcastChannel in particular, is extremely problematic because it extends a Channel interface, which is a crucial core interface of a coroutines library and we have future plans to evolve it to allow for a much more efficient/performant implementation of various channels. BroadcastChannels, when they are still in the library, pose a considerable hindrance to those future plans.

Without knowing the exact details of the implementations I guess I have to acknowledge that has a good reason. What I am using Broadcast Channels for looks effectively like what SharedFlow is supposed to to, but I don't feel well with moving to something that has been out there for not even a year and therefore is prone to quick changes (which this discussion itself is a good example for).

Besides removing BroadcastChannels (and ConflatedBroadcastChannels), what other changes are planned for the Channels API?

We plan to reworks internal Channel APIs that determine their interaction with the select {} expression. Flow will not be affected since it doesn't work with select at all, but a BroadcastChannel will because it is a Channel. We don't really have a way of supporting an improved high-performance select infrastructure in the BroadcastChannel. As a compromise, we can keep implementations of BroadcastChannel in the library for longer, but throw an exception on any attempt to use them with select. That'll let some simpler code that uses them to avoid migration for longer while giving us the ability to roll out improved channel infrastructure.

Thank you, that sounds very reasonable!

It was quite a lot of time since hot flows were introduced and broadcast channels were marked as obsolete.
Since #3621 we found that the maintenance of broadcast channels is becoming more and more harder to the extent where the very design of broadcast channels prevents us from a more efficient solutions within channel's core.

We do plan to deprecate them for good starting from 1.7.0