/cc @griesemer

I can reproduce this. It does look like a regression.

Stand-alone reproducer (no need to use loader): https://play.golang.org/p/6rledUr3Mhx

The loader type-checks the test package by type-checking the _test file incrementally, via a 2nd go/types.Files call. That API is meant to be called like this, but in the process go/types starts with a fresh (internal) interface cache which causes incorrect recomputation of interface methods.

The following diff fixes the problem:

diff --git a/src/go/types/check.go b/src/go/types/check.go
index 91df94dcbc..10e8c500ac 100644
--- a/src/go/types/check.go
+++ b/src/go/types/check.go
@@ -192,7 +192,7 @@ func (check *Checker) initFiles(files []*ast.File) {
 
        check.firstErr = nil
        check.methods = nil
-       check.interfaces = nil
+       // check.interfaces = nil
        check.untyped = nil
        check.delayed = nil

We should definitively do this since adding (test) files to a package cannot change any of the already computed interfaces (even though it may add methods to concrete types). So this is a useful optimization in its own right. That said, it's unclear yet why it's also necessary.

Change https://golang.org/cl/152259 mentions this issue: go/types: fix interface receiver type for incremental type-checking

See comments in CL as to why the suggested diff is correct and also necessary.