I would love to have this in Python 3.10, but the interaction with "decimal" context has a risk I don't know how to evaluate, neither the impact of a new "context" parameter when launching a new thread. It could collide with a "frequently used" parameter name.
I know that we are quite late in 3.10 window since rc1 is planned in a couple of days, but I think this enhancement is sensible. In fact, I discovered it after being annoyed myself with this issue (threads should have their own contexts) and studying the code to write a patch myself.
In particular, "concurrent.futures" threads should have independent contexts, like asyncio futures have. That would allow, for instance, to have a "requests.Session" object per thread since that object is not thread-safe (my use case today) and reuse it in different futures that happens to run in the same thread.
Since "contextvars" is "threading.local" correctly done, let's do it for real.
If legacy code expects a thread to be able to modify parent context, just pass that context to the thread explicitly.