I initially thought this was a regression, because I never saw it happen before 1.7. Turns out it's more subtle than that: older versions of Go would still ignore.go files with cgo directives, but balk at .c files.

$ CGO_ENABLED=0 go14 build github.com/mattn/go-sqlite3/_example/simple
../go/src/github.com/mattn/go-sqlite3/_example/simple/simple.go:6:2: C source files not allowed when not using cgo: sqlite3-binding.c
$ CGO_ENABLED=0 go14 build github.com/FiloSottile/justcgo/plusgo
$ CGO_ENABLED=0 go build github.com/mattn/go-sqlite3/_example/simple

This behaviour has landed in Go 1.4. If cgo is not used, go build is ignoring the C files now.

When CGO_ENABLED=1 without import "C", C files are not allowed and build should fail.

Did you mean 1.4? My test above shows different behaviors is 1.4 and 1.7.

I understand this might have made the behavior more consistent, but it made real-world cases like the sqlite one above much more confusing.

Did you mean 1.4?

Rejecting the C files introduced in 1.4. Sorry, it sounds like skipping them has introduced.
go build -compiler=gc prohibiting builds with C files (when CGO_ENABLED=0) happened at https://codereview.appspot.com/149720043 (go1.4).

It is more of a requirement now to ship a package with cgo and !cgo implementations because C compilers are not primarily required for Go. Implicitly scoping C files without a build tag to cgo builds is not bad but handy.

sqlite package should maybe add cgo build tag to restrict itself to cgo builds.

This is working as intended: it lets you write a cgo implementation and a non-cgo implementation in the same directory. It sounds like the package you are building has a non-cgo implementation that does nothing. You can write files that are compiled only when not using cgo by adding "// +build !cgo" tags to them.