This appears to be due to a difference in the behavior of os.Lstat on Plan 9.

On other platforms, os.Lstat(".") empirically returns a FileInfo such that fi.Name() == ".", but on Plan 9 it seems to instead return the resolved name of the current working directory.

Is that difference intentional?

What does the program in https://play.golang.org/p/OHAkKG-4Tp- output when run on Plan 9?

(I can't run it myself due to #42117.)

Is that difference intentional?

It reflects the underlying semantics of Plan 9 file system. Plan 9 doesn't have separate directories and inodes, or links - the filesystem is a tree, not an arbitrary graph. The directory entry contains the name of the file element as well as the usual 'inode' information, and that's what stat returns in the name field. No resolving needed.

What does the program in https://play.golang.org/p/OHAkKG-4Tp- output when run on Plan 9?

I copied it into /tmp, and did 'go run' from there. It outputs "tmp".

go doc os.FileInfo says that the Name field is "base name of the file". On Plan 9 that's unambiguous because files have only one name. (You can dynamically bind other names to it, but that's something else.) On other systems with hard links, it can only give "a base name" because "the base name" doesn't seem to have a meaning.

Hmm. On other systems, there is one obvious base name to choose for ., which is the name given by calling filepath.Base on the result of os.Getwd(). But they don't do that today. 😞

Given your argument above, I suppose that the Lstat behavior on Plan 9 is correct and it is the other platforms that are not quite right.

Given your argument above, I suppose that the Lstat behavior on Plan 9 is correct and it is the other platforms that are not quite right.

Hrm. The stat(1) command on Linux is consistent with Go's Stat and Lstat:

$ cd /tmp
/tmp$ stat . --format=%n
.

I guess this is just a plain old platform variation. 😞

Change https://golang.org/cl/264177 mentions this issue: cmd/go/internal/fsys: use a root other than "." in Walk tests