Thanks for the clarification. So it's not that something couldn't be done, it's rather that too dramatic measures would need to be taken.
One more alternative that I suggested earlier, to which I failed to see any comments, was this:
class MyThing(TypedDict, optional_types_may_be_missing=True):
req1: int
opt1: Optional[str]
(Obviously, with some shorter name for `optional_types_may_be_missing` argument.)
It would make no distinction between "null" and "missing", but that's what one normally wants anyway. It wouldn't work to define a PATCH HTTP API endpoint, where sending out "null" (clear the value in DB) has different meaning from not sending the field at all (no change), but it would be sufficient for most cases. It's not perfect, but perhaps sufficient (like introducing the Required key).
This would add more confusion for users because it would mean that in *some* contexts the meaning of Optional[] is different than in other contexts.
Can you please just get behind the Required[] proposal?
--