At this point I think that's pretty unlikely. Today it defaults to each package test running with coverage of the specific package under test. If you want to do a group with group coverage, that's fine, but it's not the default current users expect and it is likely not possible to specify any other way if we did change the default. It is also much less specific about helping evaluate whether a particular package's test covers that package well.

Why would group coverage be a better default?

CC @jayconrod

Personally, I would expect go test -coverprofile=[…] to default to computing coverage for all of the packages matching the input patterns.

I agree that the current default is better for evaluating whether a given package's unit-tests cover that package, but defaulting to unit-test coverage without including integration-test coverage gets the developer incentives wrong.

If users are only going to write one kind of test, I would rather they write integration tests, because those not only better represent the actual use-cases that callers are likely to care about, but also do a better job of catching mismatched assumptions across package boundaries. But since integration tests are excluded from coverage results by default, we're nudging users to write isolated unit-tests instead.

@bcmills I'm finding that I'm using a lot more blackbox testing even for so-called "unit tests". The tests that remain in the same package as the code-under-test
is pretty much relegated to functions that are not exported but are complex enough to need some guard against bugs by regression.