There's indeed a serious problem if cache invalidation relies solely on the declared semver of the package. Maybe something govulncheck could manage by comparing a package's hash on pkg.go.dev VS the remote vcs.
If you just invalidate the cache on hash mismatch, the malware problem exists the other way around:
You update a dependency to version x and check its code to ensure it's safe. Then the threat actor adds malware to that library you're depending on, and makes the old tag x point to the malicious commit. Yor coworker does "go get" to download dependencies and gets the malware.
One solution (on dev side) is to vendor, which Go has native support for. Another (on Go side) is to show a warning on hash mismatch.
That's why I suggested govulncheck; it can keep a database of suspicious packages and issue a clear warning, and it can be locally check that the hash of tagged version you're using locally is the same on GitHub.
Yeah, it's fundamentally flawed because git tags can be force-pushed over and this has happened on many open source projects in the past, leading to different mirrors hosting different content for the same version.
You update a dependency to version x and check its code to ensure it's safe. Then the threat actor adds malware to that library you're depending on, and makes the old tag x point to the malicious commit. Yor coworker does "go get" to download dependencies and gets the malware.
One solution (on dev side) is to vendor, which Go has native support for. Another (on Go side) is to show a warning on hash mismatch.