Yes, given that the entire point of type checking is to describe the correct types and catch things before runtime. If they're not able to do that, that's a design issue that needs to be fixed with typing or type checkers.

In that case, I would suggest to revert #4579.

But with Mapping, it would accept invalid uses, so that doesn't seem "strictly better" just "different for that specific use case".

But in 2.1.2, literally every invalid type was accepted. Yes, being able to reject all invalid types before runtime is ideal, but not at the cost of also rejecting valid types.

With Mapping, all invalid non-Mapping types are still rejected, and non-dict Mapping types cause a very clearly written runtime error: The view function did not return a valid response. The return type must be a string, dict, list, tuple with headers or status, Response instance, or WSGI callable, but it was a object. which cannot be misconstrued.

Surely that is still a significant improvement over 2.1.2.

In 2.1.3, where TypedDicts are not accepted, we would lose the ability to strongly type check our JSON-based API endpoints.