This is a draft PR and is not meant to be merged as it. It shows the result after merging the following changes:

• GH-141148: Ensure decimal.getcontext() returns fresh copy. #151953
• gh-154549: warning for thread_inherit_context change #154558
• gh-154562: Add ContextVar(thread_inheritable=...). #154564
• Future PR: change warnings and decimal to use ContextVar.thread_inheritable().

Related discussion is on Discourse.

Reasoning for each change:

• ContextVar.thread_inheritable(): this new API is for libraries that want to convert global state to context-local state. It was intended that they should use ContextVar() since it acts like a thread-local and also switches context for asyncio tasks. However, ContextVar() has an issue in that new threads start with empty ContextVar bindings, they don't inherit the binding of the variable from the starting thread. This was an oversight but it has been how it works since contextvars was introduced. So changing it so threads do inherit is an incompatible change (effectively, this is turning the thread_inherit_context flag on by default). The ContextVar.thread_inheritable() API allows libraries to opt-in to what will be future behavior early. Suggest to merge for the 3.15 release.
• deprecation warning: this warning will help identify code that will be affected by changing the default of thread_inherit_context to true. Ideally this warning should be in place for two releases before we change the default. Suggested to merge for the 3.16 release. Merging for 3.15 might be okay but I fear of people seeing new deprecation warnings that were not present in earlier 3.15 betas.
• Make decimal.getcontext() return a fresh copy: this is required to avoid a bug if thread_inherit_context is true or if decimal starts using ContextVar.thread_inheritable() for its context. In that case, threads inherit the same mutable decimal.Context instance of the thread that spawned them. That's not thread safe and very likely not desired (e.g. a thread modifying the decimal context could affect the context of other threads). This bug exists in current Python if you explicitly set thread_inherit_context or if you use the free-threaded build, where that's set by default. Ideally this would be merged before 3.15 final since it's a bug.
• Future PR, use ContextVar.thread_inheritable() for warnings and decimal: this change avoids deprecation warnings from these modules. Suggested to merge in 3.16. This changes decimal context slightly in the default (GIL-enabled) build (new threads start with a copy of the decimal context of the starter thread, rather than a copy of decimal.DefaultContext). IMHO, this is better but it is also an incompatible change.

In a future release (likely 3.18), we turn thread_inherit_context on by default. Then, ContextVar.thread_inheritable() and ContextVar() do the same thing. We can just leave thread_inheritable() as a soft-deprecated alias.