You can use sourcegraph to look for usages of __extra__, https://sourcegraph.com/search?q=context:global+__extra__:+lang:Python+fork:no+archived:no&patternType=literal. It only includes public code, but that still covers a lot of code. Almost all usages of __extra__ come from a few in typing_extensions and are not a TypedDict context. So current conflict amount is near 0. If it's not being used as a key today across many millions of lines of code then it's pretty safe. So I lean towards __extra__ solution as simple to describe and handles annotations as expected. In theory one way to handle conflicts would be something like, class A(TypedDict, extra_key="__custom_extra__"): __custom_extra__: type_annotation but I think need to override extra_key will be rare enough that if it's an issue one day we can revisit it then. I recently had a similar discussion pop on a serialization library and what field name to use for serializing class type. After discussion I ended up not allowing field name to be customizable as the chance of conflict seemed too low and worst case it's backwards compatible to introduce extra_key in future.