Consider the following file structure:

$GOPATH/src/example/example.go (Imports "./other")
$GOPATH/src/example/other/other.go

Currently, if you run go build example, the command will fail with local import "./other" in non-local package. In many cases, this is not a problem; for example, in this case, you could just use import "example/other" instead.

However, this quickly becomes a problem when dealing with GitHub forks. For example, let's say that the example package is a command that I've pushed to GitHub. In this case, the import line would be import "github.com/DeedleFake/example". Someone else decides that they want to contribute, so they fork the repo. Two repos now exist: github.com/DeedleFake/example, and github.com/someone/example.

The problem is that they want to make a change to other. In order to do so, they must modify every instance of the import line in example in order to build their modified version, but they have to remember to change them all back before submitting a pull request. This is tedious and error prone. In the worst case, they miss one or two of the imports and github.com/someone/example winds up importing both github.com/someone/example/other and github.com/DeedleFake/example/other.

So, I propose that relative imports be allowed inside of a GOPATH. Especially with internal packages incentifying people to split their code into multiple sub-packages, it just seems to me like it would make sense.