FileFinder only handles a single directory, and FileLoader only handles a single file, so their "path" attributes are paths in the "fspath" sense, rather than the "sys.path" or "PathFinder" sense.

Perhaps it would be worth the hassle of migrating to "fspath" as the attribute and parameter names here?

The attribute can be renamed without breaking backwards compatibility by also adding a "path" property that manipulates the renamed "fspath" attribute.

Renaming the parameters would be a bit trickier, since we would need to allow the parameter to be supplied under either name for at least 3.7, so we'd need to do something like:

1. Remove the current positional-or-keyword "path" parameter
2. Add keyword-only "path" and "fspath" parameters that default to None
3. Accept arbitrary additional positional arguments (which is already the case for FileFinder)
4. If both of the new keyword-only parameters are None, then extract "fspath" from the tuple of positional parameters (i.e. by doing "fspath, *loader_details loader_details" in FileFinder, and "fspath, * = args" in the FileLoader classes

At a documentation level, this would just be described as the parameter name being "fspath", and a versionchanged note for 3.7 saying that the parameter name changed from "path" to "fspath" and the old "path' name is still supported as a keyword argument for backwards compatibility reasons.

If we actively deprecated the old names, then the deprecation warnings would live in the access function definitions for the "path" attribute, and in the case where the "path" keyword argument was non-None for the renamed parameters.