CancellationToken is a more likely candidate for this than IProgress<T> . With IProgress<T> , you often have different T at different levels (higher level async methods combine the progress notification of their lower level await calls). With a CancellationToken , the same token is almost always passed to the lower-level async methods (provided that they support cancellation). CancellationToken supports some really advanced combinators, but they are almost never used.
The main disadvantage is that you will deviate from the asynchronous task-based template. You should keep in mind that any Microsoft or third-party code will accept an explicit CancellationToken - sp, which you will need to explicitly pull out of the context in the lowest-level async methods. In addition, programmers supporting your code base later are more likely to expect TAP.
There also arises a problem when you consider an implementation. You want the implicit CancellationToken make calls to async methods, even if they change thread contexts. I mean, consider this: method A calls ConfigureAwait(false) before waiting for the result of method B You cannot use the simple static thread-local property because you need to follow the async execution context from one thread to another.
I seem to recall how to do this (perhaps using the CallContext class?), But as soon as you do this your performance tanks (the execution context migration code is highly optimized for the default script).