I'm strongly in favor given how popular this is. I'd brought up a proposal for this in the past along with some examples and edge cases: [1]. This includes handling things like inherited TypedDicts and compatibility rules for such functions, which differ from the compatibility rules for TypedDict.
As mentioned in the above thread, the main advantages are:
1. better type safety: we get precise types for each keyword instead of using a broad `**kwargs: object`. We also forbid extraneous keyword arguments unless specified. This cannot be done right now.
2. code reuse: we can use TypedDict inheritance to avoid having to repeat the same keyword-only parameters in multiple places (and make mistakes).
This seems to be needed a lot in certain class hierarchies. For example, in Apache airflow, `PythonVirtualEnvOperator` subclasses `PythonOperator` [2]. Its constructor accepts a bunch of keyword-only parameters, uses some of them directly, and passes on the remaining keyword parameters to `PythonOperator`'s constructor. That in turn expects certain keyword-only parameters and passes the rest to its parent class constructor. So, the TypedDict hierarchy for the keyword arguments would naturally mirror the class hierarchy.
Regarding syntax, we could reuse `Unpack` from PEP 646: `def foo(**kwargs: Unpack[Movie]) -> None:` or add a new operator like `UnpackKwargs`. That would avoid a syntax change for `**Movie` unless necessary.