Wip sip23 √

How is it easy for a user to mess it up?

Somewhere in the code something has to know what things to capture: I assume this isn't the end-users code in the normal case, but library code (assuming that users don't implement twitter.util.Local themselves), where you today are doing the capturing you would just wrap the inbound EC with a Capturing/Captured EC depending on the use-case and pass that along.
Could you explain to me why this:
1) Wouldn't work
2) Would be cumbersome/easy for the end-user to mess up?

While a hybrid solution _might_ be more appropriate (change prepare's return type for more clarity) it still does not address the issues regarding testing (have I called prepare where I am supposed to, should I call it once or once for every submission?) and it still places the burden on _everyone_ that uses ExecutionContext.execute instead of only those who wish to capture things. And even then we have the problem that we simply cannot change the return type of prepare, since that would be a source-breaking change.

My own experimentations with Capturing and Captured ECs show that it's possible to achieve both local capture, deferred capture and a mix (since they can be nested)—I'd like to see that refuted if possible. If Twitter is has to migrate to ECs then it'd be the best option to deprecate `prepare` now so that once migration starts it can get onto the "Capture-track" and the pain of prepare has been lifted off the shoulders of those who do not need to capture, and if there is no plans to migrate to ECs then what's the harm in deprecating prepare? Doesn't this look like a huge win-win situation or what?