Wip sip23 √

>I agree that prepare isn't a great API as-is for the reasons highlighted, but I do believe it's repairable. I seem to have >misunderstood your intent here, that you needn't rely on an implicit def to make this work.

Which reparation an improvement over my proposal? I believe to have proven that `prepare` is not only a bad idea (as supported by @richdougherty), it is also hard to test, a single missed call to prepare will break entire chains of propagation, and it fundamentally pushes a responsibility to the consumer that the consumer shouldn't have to care about.
I have also proposed a fix that remedies most if not all of those problems (the open question is the testability, but it's provably easier since there is less ceremony required).

It is important not to do changes to the stdlib without merit and without proper gain, and I can only hope that I've made a strong enough case that `prepare` is broken, cannot be fixed without breaking binary compatibility and without degrading performance of all ECs that do not care about capture (don't pay for what you don't need).

>However, this severely compromises modularity: capture is a property of the EC, not of its uses (e.g. a Promise impl.) If I'm >using Twitter's EC, I expect my capture to happen everywhere. Otherwise, for example, I can't reliably do things like >propagate locals through third-party libraries.

That statement is fortunately false—if you pass around a Twitter EC, you are in full control over capturing at every `ec.execute` as per my CapturingEC.

@mariusaeriksen, could you elaborate more on your arguments against deprecating `prepare`? (I hope we have shown that my proposal not only covers the use-cases of prepare but also gives additional benefits)