Right now the go.mod file contains

module gopkg.in/ldap.v3

This means that I can't reference the github repo as a module, e.g. if I want to depend on unreleased changes I can't do

mbp:vault ncc$ go get -u github.com/go-ldap/ldap@master
go: finding github.com/go-ldap/ldap master
go: github.com/go-ldap/ldap@v0.0.0-20191029211349-e69ea107af8c: parsing go.mod: unexpected module path "gopkg.in/ldap.v3"
go get: error loading module requirements

My thinking is that gopkg.in made sense prior to the introduction of go modules, and there's no harm in keeping it around, but there's no reason they need to be used together. In other words, if someone not yet using go modules wants to import ldap via gopkg.in, they still can, and that doesn't require a go.mod file. If someone using go modules wants to import ldap, there's no reason why they need to do so via gopkg.in, and in fact that limits their options needlessly.

Until a few days ago when the go.mod file was introduced I could do this, e.g.

mbp:vault ncc$ go get -u github.com/go-ldap/ldap@9f0d712775a0973b7824a1585a86a4ea1d5263d9
go: finding github.com/go-ldap/ldap 9f0d712775a0973b7824a1585a86a4ea1d5263d9

But now that there's a go.mod that names the module based on gopkg.in, I can't use it except via gopkg.in, and I can only reference the versions published there.