The rationale here is that, since a module is versioned and released as a single entity, the backwards compatibility that this vet check enhances - by allowing adding or reordering fields in a struct type - is less important for packages in the same module. Using a composite literal defined in a package which belongs in a different module would still require explicit keys.

I personally prefer to be explicit more often than not with composite literals, but I also find it reasonable that in some cases where the type belongs to the same module, the check might be too pedantic given that vet is meant to be used and followed by everyone.

To implement this change the analyzer would need to be able to map a types.Package to a module name. I don't know exactly how this would work.

Something to add there - if go vet is used in GOPATH mode, or with an ad-hoc package that does not belong to any module, the current behavior would not change.

To implement this change the analyzer would need to be able to map a types.Package to a module name. I don't know exactly how this would work.

I am not currently aware of a good path from the info available in an analysis.Pass to get the module name. If this was available, one would need to communicate the module names between packages in the same module. At the moment, this means writing Facts. Likely a package fact with the module name. Checking whether the names of the modules match seems straightforward after this. Still need the first part solved though.