Feature or enhancement

Summarizing, it would consist of users being able to add Traversable objects to sys.path and having the default loaders pick them up.

Pitch

This proposal aims to simplify the implementation of import redirection and similar use-cases by introducing support for abstracted paths in our default loaders.

Loaders are a bit too low

Currently, one of the most common use-cases of custom loaders is to implement some kind of import redirection, not to add support for new module types. By import redirection, I mean that the loader maps import names to normal modules, but in different locations.
A good example of this would be loaders for packages installed in editable mode.

The loader abstraction is a bit lower level than desired for this use-case, so implementing a loader for these applications is pretty hard. One needs to either re-implement all the resolution and import logic, or subclass the default loaders and customize them.

How Traversables can help

Traversable is a protocol introduced in 3.9 to provide a path abstraction to use in importlib.resources. If we change the default loaders to use this abstraction, we remove the need for customs loaders to implement support for data sources.
Placing an abstraction at this level should allow us to better support environments that lack a native file-system, support custom ... more consistently, and even possibly remove some complexity from the import system, like zipimport, in favor of a lightweight ZipPath alternative + the default loaders.

Implementation

This would likely consist of adding a new _Path type that implements the Traversable protocol using os.path, to use with string paths, and then change the loaders to use the abstraction, instead of using os.path directly.
Some loaders use features that are not provided by Traversable, like stat, but we can ensure backwards compatibility by setting __fspath__ in our _Path implementation, and still performing those operations if a file system path is available.

I am not super worried about the performance impacts of this, as I think this abstraction should be fairly light.

Previous discussion

This is somewhat related to #89710, and is a step in the right direction for that.