For the sake of completeness, here's an example of "only print the current goroutine by default" working as documented:

$ cat f.go
package main

import "time"

func main() {
	go func() { time.Sleep(time.Minute) }()
	go func() { time.Sleep(time.Minute) }()

	go func() {
		time.Sleep(time.Second)
		panic("foo")
	}()

	time.Sleep(time.Minute)
}
$ go run -trimpath f.go
panic: foo

goroutine 7 [running]:
main.main.func3()
	./f.go:11 +0x31
created by main.main
	./f.go:9 +0x45
exit status 2

I think the distinction here is the difference between panic and throw. A panic prints only the goroutine in question. A throw prints all of them.
Normally throw is only used when the runtime discovers a bug in itself, in which case printing everything is fine, in fact helpful, in that it could be useful for a bug report on the runtime itself.
When the runtime discovers a bug in the user program, like the concurrent map write detector, we also use throw. Maybe we shouldn't, or maybe we should use a variant that prints only the current goroutine.

I see; I hadn't caught on to the distinction between panic and throw. Note that the docs simply talk about "an unrecovered panic or an unexpected runtime condition", which I would assume would cover both. So if we want to keep that distinction, maybe that's also something to clarify in the godoc.

Regardless, I agree that concurrent map writes shouldn't dump all goroutines - they aren't a bug in the runtime package itself. I'd think that any such runtime failures due to bugs in the user's code should cause something akin to the current panic, not the current throw.

This has come up in the past in the context of differentiating throws due to "user bugs" (unlock of unlocked mutex, concurrent map write, etc) and "runtime bugs" (most throws) when analyzing crashes. Perhaps we should have a userThrow for these fatal user bugs, which could also more closely match the proper GOTRACEBACK setting.

I agree that we should differentiate runtime-internal fatal errors from user-caused fatal errors, but isn't "concurrent map writes" actually one of the few cases where it is useful to see the other goroutines so you have a chance of catching the other goroutine that's writing to the map?

I think it is unlikely to actually catch the particular write itself. By the time the runtime stops that goroutine it has finished the write and moved on. (write-write conflicts might actually catch both offenders, but for read-write conflicts we only catch the read side.)
It's quite possible, however, to catch the other goroutine not too long after the write, which might still be useful (e.g. still in the same parent function, or it's doing a bunch of writes in a loop, etc.).

isn't "concurrent map writes" actually one of the few cases where it is useful to see the other goroutines so you have a chance of catching the other goroutine that's writing to the map?

Perhaps, but note that dumping all goroutines is an entirely different matter. See my mention above of a problem we ran into on production: all panics we had seen up to that point were under a kilobyte, as they only contained one stack trace. Then one day we hit a concurrent map write, and the tens of megabytes dumped all of a sudden caused the logging system to get stuck.

You can say that's something that we should fix, but it's also extremely surprising that a tiny minority of user-caused panics can surprisingly dump all goroutines :)

I wouldn't oppose if this map panic printed the stack traces of all goroutines involved in the data race, which I assume would almost never be more than a handful. If that's not possible, then I think it should just use the running goroutine.

(user experience report)

Encountered this issue at my work yesterday. We had a service crash in production due to concurrent map writes. Our debugging got slowed down a bit because our process printed stack traces for hundreds of thousands of goroutines. Our log viewer "kubectl logs " was only displaying the tail end of the stack traces, because of the length. This made it hard to understand the cause until we figured out how to get all of the logs.