Just to close off a couple of open questions:
TypedDicts in general already allow extra keys to exist (because they support structural subtyping)
The point here was that structural subtypes (that is, "child" TypedDicts) can specify extra keys, and this has implications for type checking.: Structural subtypes are subtypes, so when we type check code with a variable `x` of type `A` for some TypedDict `A`, it is already not correct to assume there are no extra keys. The value in `x` might actually have the schema specified by some sub-TypedDict `B` that adds additional fields, and therefore could include fields that weren't part of the schema of `A`.
How is this solved for `total`? Why would a similar solution as for `total` not be acceptable for `extra`?
The point about types outside of annotations was specific to if we pass a type in as `extra`, rather than a boolean. In that case, the evaluation model for the type could be complicated for a variety of reasons, it boils down to the fact that types are normal python expressions, but when they are used as annotations they get special handling (for example they are turned into strings when `from __future__ import annotations` is used). This special handling doesn't apply to types used in other syntactic places, such as in a class. This concern is specific to using a type; boolean flags like `total` (or `extra` as a boolean as in the draft PEP) are just fine.