From go help test:

Go test runs in two different modes: local directory mode when invoked with
no package arguments (for example, 'go test'), and package list mode when
invoked with package arguments (for example 'go test math', 'go test ./...',
and even 'go test .').

In local directory mode, go test compiles and tests the package sources
found in the current directory and then runs the resulting test binary.
In this mode, caching (discussed below) is disabled. After the package test
finishes, go test prints a summary line showing the test status ('ok' or 'FAIL'),
package name, and elapsed time.

In package list mode, go test compiles and tests each of the packages
listed on the command line. If a package test passes, go test prints only
the final 'ok' summary line. If a package test fails, go test prints the
full test output. If invoked with the -bench or -v flag, go test prints
the full output even for passing package tests, in order to display the
requested benchmark results or verbose logging.

Note the "if a package test passes, go test prints only the final 'ok' summary line". I think that explains what's happening here.

The documentation seems insufficient in this case; even after reading it, it seems like a stretch that a user would expect local directory mode to include output that package list mode does not.

In addition, the docs here almost seem like there should be a new paragraph starting with the second sentence of the third paragraph you quoted: "If a package test passes...", because otherwise part of that paragraph applies to both local directory mode and package list mode (e.g. the description of -benchmark and -v), while other parts do not (e.g. "go test prints only the final 'ok' summary line").

I was simply pointing out the docs that explain what is going on. If you think the docs could be improved, feel free to reopen and repurpose the issue and send a CL to do the appropriate changes.

Is that preferred over aligning the behavior of local directory mode and package list mode?

If you'd prefer that route, you could write a proposal to try to change the behavior of go test. Bear in mind that you're unlikely to succeed though, as that's a breaking change of some sort. And the current behavior was very likely designed this way on purpose.