Currently os.PathLike[str] causes a runtime error; however, typeshed sees it as valid and mypy does not throw any errors on it. 

mypy treats it as os.PathLike[AnyStr] 

I already filed a bug on typeshed, see https://github.com/python/typeshed/issues/3202

And since mypy interprets it as useful, cpython should try and support it as well.

Making an existing stdlib class generic has to be considered carefully, otherwise it may break backward compatibility.

As I wrote in the typeshed issue, I actually think the status quo is fine. But I'd like to hear you out about how it causes problems in VS Code (that can't be fixed by adapting VC Code to reality).

There is an (old) similar proposal https://github.com/python/typing/issues/402 btw.

Taking into account that this can be made only in 3.9, what is the benefit over ``from __future__ import annotations`` (that one can use already) do you see?

IMO there are only rare cases of type aliases and base classes, so I don't see much benefit. Also making it generic will require importing ``typing`` from ``os`` which may make it slower to import (``typing`` is a really heavy module, in particular because it imports many other modules).

What happened is that we have a hard time analyzing PathLike because in the pathlib stub they use PathLike[str], so when we try to analyze Path which inherits from PathLike[str], because PathLike is not generic, then we think it's an instance of an object and don't inherit from it. That means Path has incorrect bases.

Previously we assumed we only had to special case typing so we will special case PathLike as well.

Sounds like you are mixing up analyzing .pyi and .py files.

Anyway, let's not do this.