I spent quite a while figuring out why this happens this way. Clearly, cmd/go represents this as a single error object attached to package x, and thus can only attach a single line number to it (and "a" happens to win).

In the modload layer, modload.(*loader).resolveMissingImports calls modload.queryImport("x"), which returns a modload.ImportMissingError, which resolveMissingImports saves to x's modload.loadPkg.err field. This error is the one grain of sand that eventually turns into the pearl reported on package "x" and as deps errors on "a" and "b" by go list. Package "x"'s modload.loadPkg eventually gets stored in the modload.loaded.pkgCache.

In the load layer, load.PackagesAndErrors -> load.loadImport(..., "./a", ...) -> ... -> load.loadImport(..., "x", ...). This calls load.loadPackageData -> modload.Lookup(..., "x"), which fetches "x"'s load.loadPkg from the load.loaded.pkgCache and returns the err field. load.loadImport passes this error into load.(*Package).load -> load.setLoadPackageDataError, which finds the position of the import of "x" via the importPos stack, and wraps the modload.ImportMissingError in a load.PackageError. In this example, since we first came to "x" via "a", setLoadPackageDataError sets the load.PackageError.Pos field to "a"'s import, even though the PackageError itself is attached to x's load.Package object.

Later, we see load.loadImport(..., "./b", ...) -> ... -> load.loadImport(..., "x", ...), which finds "x"'s load.Package in load.packageCache, and thus doesn't enter load.(*Package).load, so the position in "a" remains attached to "x"'s load.Package.

This was all sufficiently complicated that I wasn't really sure where to change how the error gets attached to packages. If we don't want "x" to be represented at all in the go list output, then I think the modload layer should attach the modload.ImportMissingError to "a"'s and "b"'s modload.loadPkg and not create a loadPkg for "x" at all. Then I think the rest would "just work."

I missed a step before modload.(*loader).resolveMissingImports above. During modload.loadFromRoots, modload.(*loader).pkg and modload.(*loader).load together walk the import graph. Eventually, pkg is called for "x", which constructs a loadPkg for "x" and calls load. load calls importFromModules, and at the end of that function is a if mg != nil check that actually constructs and returns the ImportMissingError for x. This is the ImportMissingError that resolveMissingImports eventually picks up on.

This might be a duplicate of #26909.