You mentioned that the use of `__extra__` would lead to an ambiguity. The purpose of a specification is to remove such ambiguities, so I don't think it would be ambiguous. It would preclude the use of a TypedDict with an actual key named `__extra__`. Dundered names are supposed to be reserved for stdlib functionality, so using such a name as a key in your TypedDict would be ill advised.
Of course the specification would need to find a way to resolve the ambiguity. Your idea was also my first idea - exclude the possibility of an "__extra__" key. I think, that would be unexpected and and strange restriction from the user's perspective. "__extra__" is a valid dictionary key. While it is common to reserve dunder names for object attributes, this is not the case for dictionary keys. Not having the possibility to use every possible dictionary key on a TypedDict specification for reasons of internal implementation looks like bad design to me.
Any time we allow types to be specified outside of type annotations, it tends to create problems. The interpreter must evaluate them immediately even if `from __future__ import annotations` is used.
How is this solved for `total`? Why would a similar solution as for `total` not be acceptable for `extra`?