go/packages.Load() returns different types.Named for identical code

I'm trying to determine if two types are identical with go/types.Identical, and suprisingly enough, types of the same piece of code returned by different packages.Load calls are always different.

Am I making a wrong assumption on those APIs?

package main

import (
	"fmt"
	"go/types"

	"golang.org/x/tools/go/packages"
)

func getTimeTime() *types.Named {
	pkgs, err := packages.Load(&packages.Config{
		Mode: packages.NeedImports | packages.NeedSyntax | packages.NeedTypes | packages.NeedDeps | packages.NeedTypesInfo,
		Overlay: map[string][]byte{
			"/t1.go": []byte(`package t
			import "time"
			var x time.Time`),
		},
	}, "file=/t1.go")
	if err != nil {
		panic(err)
	}
	for _, v := range pkgs[0].TypesInfo.Types {
		return v.Type.(*types.Named) // named type of time.Time
	}
	panic("unreachable")
}

func main() {
	t1, t2 := getTimeTime(), getTimeTime()
    if !types.Identical(t1, t2) {
        fmt.Println(t1, t2, "are different")
    }
}

Apparently, there is a piece of hidden doc explaining all these (it attaches to nothing, so it's not on godoc)： https://cs.opensource.google/go/x/tools/+/master:go/packages/doc.go;l=75

> Motivation and design considerations
>
> The new package's design solves problems addressed by two existing
> packages: go/build, which locates and describes packages, and
> golang.org/x/tools/go/loader, which loads, parses and type-checks
> them. The go/build.Package structure encodes too much of the 'go
> build' way of organizing projects, leaving us in need of a data type
> that describes a package of Go source code independent of the
> underlying build system. We wanted something that works equally well
> with go build and vgo, and also other build systems such as Bazel and
> Blaze, making it possible to construct analysis tools that work in all
> these environments. Tools such as errcheck and staticcheck were
> essentially unavailable to the Go community at Google, and some of
> Google's internal tools for Go are unavailable externally. This new
> package provides a uniform way to obtain package metadata by querying
> each of these build systems, optionally supporting their preferred
> command-line notations for packages, so that tools integrate neatly
> with users' build environments. The Metadata query function executes
> an external query tool appropriate to the current workspace.
>
> Loading packages always returns the complete import graph "all the way
> down", even if all you want is information about a single package,
> because the query mechanisms of all the build systems we currently
> support ({go,vgo} list, and blaze/bazel aspect-based query) cannot
> provide detailed information about one package without visiting all
> its dependencies too, so there is no additional asymptotic cost to
> providing transitive information. (This property might not be true of
> a hypothetical 5th build system.)
>
> In calls to TypeCheck, all initial packages, and any package that
> transitively depends on one of them, must be loaded from source.
> Consider A->B->C->D->E: if A,C are initial, A,B,C must be loaded from
> source; D may be loaded from export data, and E may not be loaded at
> all (though it's possible that D's export data mentions it, so a
> types.Package may be created for it and exposed.)
>
> The old loader had a feature to suppress type-checking of function
> bodies on a per-package basis, primarily intended to reduce the work
> of obtaining type information for imported packages. Now that imports
> are satisfied by export data, the optimization no longer seems
> necessary.
>
> Despite some early attempts, the old loader did not exploit export
> data, instead always using the equivalent of WholeProgram mode. This
> was due to the complexity of mixing source and export data packages
> (now resolved by the upward traversal mentioned above), and because
> export data files were nearly always missing or stale. Now that 'go
> build' supports caching, all the underlying build systems can
> guarantee to produce export data in a reasonable (amortized) time.
>
> Test "main" packages synthesized by the build system are now reported
> as first-class packages, avoiding the need for clients (such as
> go/ssa) to reinvent this generation logic.
>
> One way in which go/packages is simpler than the old loader is in its
> treatment of in-package tests. In-package tests are packages that
> consist of all the files of the library under test, plus the test
> files. The old loader constructed in-package tests by a two-phase
> process of mutation called "augmentation": first it would construct
> and type check all the ordinary library packages and type-check the
> packages that depend on them; then it would add more (test) files to
> the package and type-check again. This two-phase approach had four
> major problems: 1) in processing the tests, the loader modified the
> library package, leaving no way for a client application to see
> both the test package and the library package; one would mutate
> into the other. 2) because test files can declare additional methods
> on types defined in the library portion of the package, the
> dispatch of method calls in the library portion was affected by the
> presence of the test files. This should have been a clue that the
> packages were logically different. 3) this model of "augmentation"
> assumed at most one in-package test per library package, which is
> true of projects using 'go build', but not other build systems. 4)
> because of the two-phase nature of test processing, all packages that
> import the library package had to be processed before augmentation,
> forcing a "one-shot" API and preventing the client from calling Load
> in several times in sequence as is now possible in WholeProgram mode.
> (TypeCheck mode has a similar one-shot restriction for a different
> reason.)
>
> Early drafts of this package supported "multi-shot" operation.
> Although it allowed clients to make a sequence of calls (or concurrent
> calls) to Load, building up the graph of Packages incrementally, it
> was of marginal value: it complicated the API (since it allowed some
> options to vary across calls but not others), it complicated the
> implementation, it cannot be made to work in Types mode, as explained
> above, and it was less efficient than making one combined call (when
> this is possible). Among the clients we have inspected, none made
> multiple calls to load but could not be easily and satisfactorily
> modified to make only a single call. However, applications changes may
> be required. For example, the ssadump command loads the user-specified
> packages and in addition the runtime package. It is tempting to
> simply append "runtime" to the user-provided list, but that does not
> work if the user specified an ad-hoc package such as [a.go b.go].
> Instead, ssadump no longer requests the runtime package, but seeks it
> among the dependencies of the user-specified packages, and emits an
> error if it is not found.