Unfortunately, I think the current implementation is subject to a serious race condition and shouldn't be merged.
Any changes that occur in the producer while the iterator is between calls to next are lost. I described the scenario in which this occurs during the pitch phase, here but you can also get the same problem by adding a try? await Task.sleep(for: .seconds(1.0)) after the print line in the first example in the Behavioral Notes section of the proposal – all values after the first will be lost and no matter how long the iterator waits, it will never receive another value.
I think this is the same problem discussed by @jamieQ in the previous reply.
The proposal mentions values that "slip between isolations" – which would be fine if these were simply aggregated. But from the point an iterator is constructed, it should always know that some kind of value change has occurred, so that when next is called again, it can take the "prime the pump" path. Instead, the iterator is completely unaware and potentially every value in the sequence after the first may be lost.
I'm not sure how you'd maintain tracking of value changed between calls to next but without it, I can't see this being usable. It is just a deadlock waiting to happen.