When pkgsite sees that a module path does not match the path in the go.mod file, it marks the module as "alternative" and does not process or display it. If a module does not have a go.mod file, then pkgsite always processes and displays it, even if people would consider it "alternative."

For example, github.com/Azure/azure-sdk-for-go does not have a go.mod file, and may never have one. But that path is clearly the canonical one; all the documentation and sample code uses it. Forks just sow confusion and interfere with processing legitimate modules.

Even if a module has a go.mod file, alternatives at older versions that do not have one are processed and displayed. For example, github.com/Shopify/sarama last lacked a go.mod file at v1.20.1, over three years ago, but pkgsite still displays github.com/shopify/sarama (note the lowercase "s"). Again, this is confusing (see #52192).

A simple solution would be to maintain a list of alternative module paths. Incoming modules on this list would be marked "alternative" in the database, and would not be processed. Existing versions would be removed. We would add paths to this list when users brought them to our attention, or when we noticed that they gummed up processing.