I did some digging into this, are you seeing this issue when scanning source code with go.mod or Go binaries?

I think the go.mod case should have a different fix, and I think the go binary case could also have a slightly different fix. I assume we are, in fact, using the packages library now to determine the go.mod case, which should be returning the correct modules, that match the go.mod, and similarly should just use those directly rather than being split to subpaths at all.

For go.mod, I think we should be using the full value we found in the go.mod or go.sum, not processing it to have any subpaths -- these are modules already. The subpath from the PURL spec is "used to point to a subpath inside a package" -- package, not module.

For the binary case, we could think about extending the online license lookup to include identification of the module paths (not asking for this as part of your PR here), but default to a slightly different behavior that looks for a /v# anywhere within the path before falling back to <host>/<segment1>/<segment2>, though a package with /v# doesn't necessarily mean the module has that, we need the go.mod to be able to tell for sure, though I suspect most modules are good citizens and update when using this versioning scheme. EDIT: I was conflating this with something else we're working on, but today with binaries, we also get module names, not packages, and these should similarly be used directly. At such time as we surface packages, we will have some additional metadata that may be output in a PURL subpath somewhere, but for all current processing we should use module names directly.