I suppose we could deliberately insert the package name when referring to a package scope variable that has the same name as a predeclared identifier. That seems a bit strange, but I guess it's not a common case.

@ianlancetaylor It makes sense that if fmt.Printf says the type is main.int64, then the compiler should also say that the type is main.int64.

Well, no, those are two different contexts. The reflect package uses a package name in front of every type name (other than predeclared types) because otherwise it would be ambiguous. The compiler does not normally use a package name in front of type names defined in the package being compiled, because a compiler error message is clearly in the context of the package being compiled.

@ianlancetaylor Go's type declarations are kind of unintuitive. Like take this example:

It's not obvious what the underlying type is or where that type (in this case main.int64) is coming from. Like the first two variables of type main.int64 are 32 bit ints and the second two variables of type main.int64 are 16 bit ints.

I opened up a similar issue regarding type declarations, but this time with pointer types:
#38890

You're right, the compiler does generate two different types, both named main.int64. This doesn't have anything to do with the fact that the type is named int64. It happens for any other type too. The types are not the same, as you can see by comparing reflect.TypeOf(I1) and reflect.TypeOf(It3), but they have the same name. That doesn't seem ideal. I filed #38893.

Duplicate of #38893