The package section of most .go files is redundant. This could be inferred by reusing the directory name. Or matching the first entry of a sibling. Go applications written in cmd//main.go can automatically infer the main package.
It’s strange that popular Go linters recommend applying a docstring for the package, but only in an arbitrary one .go source file, among those that contribute to that same package. Copying, pasting, and maintaining duplicate docstrings is not… maintainable.
The package declaration is independent of file-system requirements. So your package name can include special characters (e.g. unicode-symbols) which your file-system may not allow in a directory name. Your directory-names may use a different encoding (ANSI…?,) than your source-files. Your package name is case-sensitive while your file-system may ignore casing in folder names.
Your file-System may also permit symbols in directory names, which are not valid for package names (e.g. spaces " " or hyphens “-”)
The package declaration provides the single canonical name for your package in the encoding of your source-files. Your directory name should by convention by the closest approximation to this name your file-system (or better, the file-systems of all involved maintainers) can support.
One solution is to restrict directory and file path names accordingly.
As an aside, it’s worth publishing a linter to warn on various spurious file path characters, as they tend to break a great many things.
This solution would only work in one direction. What about package names, which are not supported by your file-system? What about the package “Ω” ? This is a valid package name, but not supported by all file-systems. But I can create a folder called “omega” and call the package “Ω” for a smaller import name and it is supported without problem on all file systems.