CL 196338, fixing #34333, introduced a data race by caching the result in n.underlying without protecting n with a lock.
Previously, if you had packages A and B both importing C, it was safe to run types.NewChecker(...).Files() on package C's files and then type-check A and B in parallel goroutines both of which returned C's type-check information from their types.Config.Importer.
But now both A and B might end up calling underlying or Underlying on the same type, and the writes updating the new cached value race. For example, here is one trace from #31749:
This matches up with what I've been seeing. Before CL 196338 it was okay to concurrently type-check two packages that depend on the same package, which golang.org/x/tools/go/packages does, but not after. I've been running into the second (validType) race consistently.