(I think you mean types.PkgName in the title and note.)

My dissenting opinion: In a qualified identifier such as fmt.Print, the correct definition of the imported package name fmt is unambiguously the "fmt" import in that file. Admittedly, that might be obvious much of the time, because the identifier fmt matches the package name "fmt", but often the relationship is more obscure. Perhaps it's a renaming import, import bar "foo". Perhaps the package's name does not match its last segment, so what you see is import "bar" but the name actually defined is fmt. Perhaps fmt is a package-level declaration in another file that you assume is an import because... who would do that? For these reasons, having the tools take you from the fmt in fmt.Println to the true declaration of fmt is less confusing. Furthermore, as you point out, there is no canonical declaration of a package: you can choose the one in the longest file, the first file, the file with the package doc comment, but it's rather arbitrary.

If you want to visit the fmt.Println function, it's easy to remember to invoke go-to-definition on the Println part of the name.

(I think you mean types.PkgName in the title and note.)

Thanks - fixed.

having the tools take you from the fmt in fmt.Println to the true declaration of fmt is less confusing

To be clear, the existing go-to-definition behavior would not change. The "fmt" in "fmt.Println" will still take you to fmt's declaration, be it an import spec or some other object in your package. I'm proposing we add "go-to-type-definition" if "fmt" is a *types.PkgName. For regular objects, "go-to-type-definition" takes you to where the object's named type is declared. Currently there is no behavior implemented for "go-to-type-definition" of *types.PkgName.

In a qualified identifier such as fmt.Print, the correct definition of the imported package name fmt is unambiguously the "fmt" import in that file

Completely agree; I think the import spec is the only sensible place to jump to for a qualified identifier.

I'm proposing we add "go-to-type-definition" if "fmt" is a *types.PkgName

I for one am a bit lost about what's being proposed here; can you post a code example, to make the discussion about the AST/types concrete?

I'm proposing we add "go-to-type-definition" if "fmt" is a *types.PkgName. For regular objects, "go-to-type-definition" takes you to where the object's named type is declared.
Currently there is no behavior implemented for "go-to-type-definition" of *types.PkgName.

Ah; that sounds completely reasonable.

Let me emphasize again that there are two different varieties of "jumps". LSP can jump to you an identifier's definition, or can jump you to an identifier's type definition. I am only proposing behavior for the latter.

First a review of existing behavior not involving packages. "<>" indicates cursor position:

type myType int // "myType" TypeName declaration (typeDecl)
var foo myType // "foo" object declaration (fooDecl)
f<>oo + 1 // "foo" object use (fooUse)

If cursor is on fooUse as indicated, jump-to-definition takes you to fooDecl, and jump-to-type takes you to typeDecl.

Now with packages:

import "fmt" // "fmt" object declaration (fmtDecl)

func foo() {
	f<>mt.Print() // "fmt" object use (fmtUse)
}

If cursor is on fmtUse as indicated, jump-to-definition takes you to fmtDecl. That is existing behavior and will not change. The question is where should jump-to-type take you? I am proposing it take you to the "fmt" package declaration in one of the files in go/src/fmt/.

The conclusion from the golang-tools meeting is that we can support this behavior with textDocument/implementation instead of textDocument/typeDefinition, just because it's a bit more intuitive.