I liked AsyncStream-based solution from here, especially in the context of Bluetooth interactions it make sense to use it as there is a stream of events from device.
As a general solution to that, I'm in favour of solution with some sort of AsyncLimiter suggested here, as it will effectively do the desired thing (serializing method execution) without introducing more to actors.
I'm still not sure if that's what is needed to address the issue with continuation cancellation. The patterns as alternative it forces to use seems more appealing to me. If we'd have documented pattern on how to address this, that might be less intrusive and beneficial approach. Yet I might be wrong here, as cancellation not easy topic.
If the API that is used does not support cancellation, what will change having continuation automatically cancelled, as the work is not being cancelled anyway?
In overall, as was stated later in the latest thread on actors, we clearly miss proper understanding and patterns guide for new concurrency world, as well as rich stdlib tools to handle various cases that arise more frequently in the real world, so that we don't re-implement them on a constant basis. Latter especially is probably is inevitable transition period, that would've been anyway, since there is a need of a time to collect use cases.
Thank's for the thread, and collection of common cases (and solutions).