This would make it impossible to use structs as map keys.

Good point. Most structs shouldn't be used as map keys, but we want that to work. What about having a way to mark structs as copyable then? Some small keyword, perhaps? Obviously copyable structs can't contain non-copyable structs.

(I'm assuming we don't want to open the box of comparable but non-copyable types.)

Many structs are safe to copy, though. The sort of thing you're asking for is a property of languages with a different philosophy from Go and doesn't fit well in Go's model.

Would it work if it used package boundaries? Structs with inaccessible fields are non-copyable?

See previously #23764 and #8005.

Thanks, that's useful background. Should I write up the accessibility-based proposal in more detail?

A current way to declare that a struct is not copyable is to add both a Lock and Unlock method, even if the method doesn't do anything. That will cause "go vet" to complain about attempts to copy the struct. If you don't want to expose the methods, you can instead add them to a zero-length unexported struct, and embed that struct in the exported one. See, e.g., https://play.golang.org/p/ovFyFQHzZFH (the playground will run "go vet" when you click on the "Run" button).

We are not going to change the default for how structs work in Go, so closing this specific issue.

It looks embedding a non-exported struct doesn't prevent the methods being exposed: https://play.golang.org/p/oahXcIL11j3

It looks std packages use non-embedding general noCopy fields:
For example:

type WaitGroup struct {
	noCopy noCopy

	state1 [3]uint32
}