What should happen if deliver_cancel raises an exception? In the current implementation, the shielded cancel scope will prevent it from propagating until the process exits, which might take a while if the crash occurred before signaling the process in any way. Maybe on exception from a user-specified deliver_cancel we should call the default deliver_cancel to kill the process? Or just kill() since

It's very common to use "infinite" streams that have the same lifetime as the operation that consumes them. In fact, in the wild thus far, this is more common than actually having a meaningful return value. It's a pain then to have the Subscription interface always need to specify two generic parameters, T and TReturn every time. If most of the time a subscription is infinite, then it probab

I totally forgot we have machinery for this in the "muti program" tests. We can likely reuse this on the "external ctrl-c" tests as well!