This can still cause a collision if I have a package named a/b and a package named a_b (unusual but not impossible).

Another option is to preserve the directory structure, so we'd end up with for example a/b/c.test. (I'd love if that were a thing for go build since you can also get collisions there.)

or just use a different separator like -

There is a tradeoff between ergonomics and API complexity: you always have the fallback of running go test -c on the packages individually, although getting the concurrency right could be a little tricky.

@bcmills while that is true its going to be dramatically less efficient than a single invocation. https://blog.howardjohn.info/posts/go-build-times/#concurrent-builds showcases this a bit; running two compile jobs concurrently in different processes seems to get very very little caching benefits.

https://blog.howardjohn.info/posts/go-build-times/#integration-tests shows another concrete example of how we would use this, specifically to take advantage of the superior build times when compiling multiple things in a single go invocation

Another method is to generate the binary in its own directory to avoid conflicts (a simple example), but this will break compatibility.

Maybe we could add a new flag to do this.