I think the responses so far provide strong evidence against the current proposal of simply changing the meaning of TypeGuard. Which is sad, because it seems clear to me that the newly proposed semantics are better, and it’s confusing for users to have two objects that do almost but not quite the same thing. However, for a feature specified in a PEP, maintaining compatibility is important.
I don’t like the name “StrictTypeGuard”. “Strict” can mean a lot of things, and it’s not particularly obvious that the new behavior is more “strict” than the existing one. It’s different, but not necessarily more strict.
If we add a new object, I think it would make sense to make it support only the “strict” version, in the terminology of the table in PEP 724 – Stricter Type Guards | peps.python.org. That is, we would require that the StrictTypeGuard return type R is consistent with the StrictTypeGuard input type I. Users who want the “non-strict” behavior would simply continue to use TypeGuard.
If so, we could say that the new construct always narrows the type to a type that is narrower than before. Could we come up with some name that incorporates this concept? Perhaps TypeNarrower.