Any idea how the spurious file was created in the first place?

They are a standard part or macos from what I understand. I normally just add ._* to my .gitignore file. In this case I was not using VCS, since I was testing go module support with a non VCS dependency, i.e. local module using the 'replace' workaround. Hence my confusion with the reported error message.

We should probably reject .go source files with leading dots entirely.

CC @jayconrod

I wouldn't be surprised if some packages were broken by the removal of dot files. I know at least some repos rely on directories with a dot or underscore prefix for packages that aren't built automatically by go build ./....

Excluding file names with the prefix ._ seems reasonable to me though.

Should these be rejected with an error or ignored? If the OS is creating them automatically for search indexing, ignoring might be the right option.

Should these be rejected with an error or ignored?

I think we should reject them explicitly, since they likely used to be allowed: better to give an error than to silently compile a package that is missing some of its (possibly-exported) identifiers.

I think if you only ignore the ._ files you'll avoid the issue with .dir or _dir mentioned above.
macos includes a tool to delete these system files: 'dot_clean .' but that would mean having to run that before every build if this was treated as an error, since there is no knowing when the OS might create more.