Go modules use a go.mod file to specify various things. One of the directives that they can include is the go directive, which sets 'the expected language version of the module', to quote the specification's words. The specification goes on to say a bit about what it's used for.

A 'go' line in go.mod does not limit what versions of Go will (try) to build the module (well, packages in the module), although of course if the module uses something that's not in older versions of Go, building will probably fail. This is important behavior, because in current versions of Go, running 'go mod init' will write the current version of Go into your new go.mod file as the 'go 1.nn' version. This is reasonably behavior and probably won't cause you problems, but you might want to watch out for it. The Go version specified in the go.mod can predate modules; in my assortment of Go programs (and vendored packages), I have one that has 'go 1.9' and two that have 'go 1.10'.

I have a collection of various people's Go programs, their vendored modules, and the dependent packages for the remaining non-modular programs sitting around. In that collection, the distribution of Go versions in go.mod files is this:

    31 go 1.13
    23 go 1.14
    20 go 1.12
    15 go 1.15
    15 go 1.11
     2 go 1.10
     1 go 1.9

(A real study should try to do some measure of the most frequently imported or used Go packages.)

I don't think 'go' directives are ever automatically updated by Go module commands, so this represents some combination of what Go version the modules were created with and what Go version people have explicitly decided to call for (whether to insure backward compatibility or to set a minimum version).

I expect that in the future we're going to see a burst of 'go' directives that specify Go 1.17 or whatever Go version modules become mandatory in, as people are forced to turn long ignored programs into modules. Some of that may be happening now in Go 1.16, since Go will now prod you about this if you haven't explicitly set $GO111MODULE to something.

PS: The development version of Go generally considers itself to be one Go version in the future for this sort of thing, so right now if you do a 'go mod init' with a development version it will create a go.mod with 'go 1.17' in it. This is reasonable behavior, but might be slightly surprising.