Overall it looks good to me. I just have a question that's is not strictly related to this PR, please consider the following code:

from opentelemetry.context import Context

Context.a = 'a'
print(Context)
with Context(a='foo', b='bar'):
    print(Context)
print(Context)

It prints:

AsyncRuntimeContext({'a': 'a'})
AsyncRuntimeContext({'a': 'foo', 'b': 'bar'})
AsyncRuntimeContext({'a': 'a', 'b': None})

Is that correct to print 'b': None outside the context? Should we worry about the number of slots?

Is that correct to print 'b': None outside the context? Should we worry about the number of slots?

Good question! The current Context design is to treat non-existing value and None the same way.

Removing a slot would be a nice-to-have thing, however it comes with high cost of introducing a contention on the hot path.

Regarding the number of slots and memory consumption, we probably should be explicit that Context is similar like TLS (thread local storage), which should be properly planned instead of being used for random stuff. Thoughts?

Overall it looks good to me. I just have a question that's is not strictly related to this PR, please consider the following code:

from opentelemetry.context import Context

Context.a = 'a'
print(Context)
with Context(a='foo', b='bar'):
    print(Context)
print(Context)

It prints:

AsyncRuntimeContext({'a': 'a'})
AsyncRuntimeContext({'a': 'foo', 'b': 'bar'})
AsyncRuntimeContext({'a': 'a', 'b': None})

Is that correct to print 'b': None outside the context? Should we worry about the number of slots?

I think that's undesired behavior. It will not have an effect in many cases I imagine, but it will definitely be confusing for the use case where None is a possible real value rather than an indicator of an absence of one.

Sorry, just read the reply. Something you could also do is have a stacked object proxy that recurses upward, and push / pop off the stack. This would enable appropriate values for when something is found / not found, at the cost off lookup.

I guess maybe alternatively it would be fine if the caveat was documented somewhere like the docstring.

Poking around, ContextVar supports very fast get/set/delete via this special-purpose black-magic data structure.

I think we've talked about it before, but if we're willing to drop support for other kinds of backing context we may get a much faster and simpler API by using ContextVar directly.

I think with a bit more careful implementation and maybe some API changes, we could at least have our implementation have little to no overhead over ContextVar if ContextVar is used internally.

LGTM as Context(...) or Context.use(...). But I don't think I understand your comment about contention. Why is del self[key] significantly worse than self[key] = None?

We have a potential contention in get and set, so we don't ask for explicit slot registration (e.g. slot = ContextVar('var', default='foobar').
The optimization was to have a small lock with assumption that slot is only going to be registered, but not unregistered. In this case, if people call register_slot (directly or indirectly via get/set) in some initialization code, there is no contention at all in the hot path.

It looks great overall, going in the right direction.