Whether or not this is a breaking change is up for discussion. I see it as just a clarification for both consumers and implementors. I.e. if you're affected by these new trap-on-drop semantics, you were already buggy to begin with.
FYI, the preview1 component adapter always performs a blocking flush on each write regardless of non-blocking status. So those users are already good to go.
This PR provides a clear answer to an outstanding issue regarding silent data loss on drop.
This change is in line with the general structured concurrency direction the component-model is heading in: https://docs.google.com/presentation/d/1bWUO1Z9swQ4KSmoeUMTwIFYurasn14xFy4o-G8nE15w/edit#slide=id.g2b22cdef62b_0_95
Whether or not this is a breaking change is up for discussion. I see it as just a clarification for both consumers and implementors. I.e. if you're affected by these new trap-on-drop semantics, you were already buggy to begin with.