Build output caching does not key off the current module's source?

IIUC, a job with cache enabled goes roughly like this (with defaults):

1. (setup-go) restore: download and extract cache blob, keyed by (among other things) go.sum
2. (user step) build something
3. (setup-go) save: if cache has key, skip. Otherwise, make a cache blob containing the "module" cache (i.e. source code) the build cache at ~/.cache/go-build/ and upload it with that key.

The key is:

const primaryKey = `setup-go-${platform}-${linuxVersion}go-${versionSpec}-${fileHash}`;

--- https://github.com/actions/setup-go/blob/main/src/cache-restore.ts#L34

But that doesn't include any inputs from the current module's source (other than go.sum)? So really, we're just caching the build outputs of the dependencies?

(Or to be more precise, we bundle all of ~/.cache/go-build, but only when go.sum changes. If we did a build of the current module, then the build cache will contain its build objects. But it will never get updated if only the source of the current module changed.)

It's unclear if this is intended or an oversight. The README.md definitely isn't explicit that the current module's source is not considered WRT to the cache key and whether a save needs to happen.

Also, I haven't really thought about it, but I'm not sure how cache test results play into this.

Start with src/cache-restore.ts around line 34 and the README.md caching documentation. Trace how the cache key, ~/.cache/go-build contents, and save behavior relate to current-module source and cached test results. Done means the intended behavior is established and the implementation or documentation clearly reflects it, with relevant tests updated if applicable.