These functions already exist in a different form:

import "io/fs"
...
root := os.DirFS("/")
...
f, err := root.Open(path)
dirs, err := fs.ReadDir(root, path)
fi, err := fs.Stat(root, path)

Note, all fs.FS paths are "unrooted" so there is still a fundamental difference with os.Open, etc.. The docs for fs.ValidPath have more details.

The different form is exactly what is the limiting factor today, which is that DirFS is unrooted and does not allow access outside of the initial directory. If I start with os.DirFS("/"), then that is not the directory I am currently in -- os.Open handles either a rooted path or a cwd path.

Given the current unrooted aspect, this proposal is likely asking to relax that restriction. There's likely a good reason for the restriction that I'm unaware of, though.

From the draft design:

The use of unrooted names—x/y/z.jpg instead of /x/y/z.jpg—is meant to make clear that the name is only meaningful when interpreted relative to a particular file system root, which is not specified in the name. Put another way, the lack of a leading slash makes clear these are not host file system paths, nor identifiers in some other global name space.

OS paths and fs.FS paths are fundamentally different. fs.FS doesn't have concepts like "relative to current working directory" and "OS root directory". Relaxing the API to accept "/" would lead to the confusion described above. #42716 exists to make these differences clearer to developers.

It's probably better/less buggy to translate paths to fs.FS style before using the API. Eg, convert to an absolute path and remove the "/" prefix. Perhaps this translation functionality could be added to the os package?

Somewhat related: #44279.

#44286 also highlights some difficulty using relative paths.

Perhaps this translation functionality could be added to the os package?

This runs into the problem of dealing with the current working directory, which would be at a different path prefix. Rereading the proposal and ValidPath documentation, maybe fs.FS is not meant to replace os in many use cases (e.g. CLIs), which is an unfortunate limitation.

I wanted to write an FS for CLIs that would be able to open files or URLs, e.g. my-cli -open example.txt or my-cli -open http://example.com . I ran into the problem that there's no great way to do the translations, especially around absolute paths. In the end, I think the trouble was an FS represents a collection of files, but a CLI probably only wants one file (e.g. an io.ReadCloser), so it's not a good fit.

fs.FS very clearly disallows paths starting with / or with ../ or even with ./ - they must be rejected by any valid Open implementation.
That ship has sailed and cannot be turned back.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Is there any way to make fs.FS broadly useful for rooted filepaths, or is that a nonstarter? If it's a nonstarter, this proposal should be closed.

Existing fs.FS implementations are incompatible with "rooted" paths, I can't see how this could be changed without breakage.

This issue, and a number of issues linked here (#44279 in particular) highlight the difficulty of translating between OS and fs.FS paths.

It may make sense to provide functionality to sanitise OS paths so they are suitable for fs.FS. Eg, via some combination of filepath.Abs and filepath.Rel. This is a very common need for anyone wanting to use fs.FS to abstract working with a collection of files.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group