Presently the "package" is required in each go file. The package dictates the name of the library when imported somewhere else. Often it matches the directory name of the package but not always. In these cases when a library is imported this defined package must be used to call the code from this library instead of the name of the directory.

For example:

file: github.com/foo/bar/bar.go
package "bar"

func DoSomething() {}

file: github.com/foo/baz/baz.go
package "baz"

import "github.com/foo/bar"

func Bar() {
  bar.DoSomething()
}

vs

github.com/foo/bar2/bar.go
package "bar"

func DoSomething() {}

github.com/foo/baz/baz.go
package "baz"

import bar "github.com/foo/bar2"

func Bar() {
  bar.DoSomething()
}

I think the package keyword should be made optional, only for backwards compatibility, and the directory of the go files should be assumed as package name automatically. This will allow us to simplify refactoring(just rename a directory instead of all uses of the package keyword in that directory), plus it will simplify refactoring imports - there will no longer be a need to scan the imported library and look for the package name, instead the directory name will be used right away. If two packages with the same directory are imported, import aliasing still works like before.

Some may say that package keyword is required for the build functionality, but I think that, since main() is a magic function name, whenever a package contains this method, it should be automatically assumed it is the main package(build/functionality-wise, not name-wise..unless the directory is called main, of course) and can be compiled into executable and does not have to be specifically named as main.