Did the extra output go to stdout, or just to stderr?

(CC: @rsc @myitcv)

I've just given this a try, and extra output goes to stderr. Additionally, it's not just triggered by using the replace directive, it's any time vgo needs to find a dependency, e.g. if you wipe out your vgo cache and then run vgo list -m -json it'll list every module your project depends (to stderr) then finally print the JSON to stdout when it's done.

@bcmills this picks up on what we were discussing back in https://go-review.googlesource.com/c/vgo/+/118316

Would one solution here be to add (and document?) a -progress flag which takes a single argument, the path to a file? If provided, progress would be written to this file (the file would in all likelihood be one half of an os.Pipe()); else progress would be written to stderr (which works for the default terminal usage). Errors are written to stderr regardless, and cause a non-zero exit code (unless -e is provided, the current behaviour of go list). That way any tool consuming the output of vgo list (-m) -json would provide -process and be able to consume CombinedOutput, safe in the knowledge the it would contain only valid JSON unless an error was also returned, in which case CombinedOutput would also have error messages etc interleaved. This would also give tools the ability to relay progress to the user if they need to.

That said, I'm unclear if this pipe approach works on Windows...

This is working as intended.
All tools must separate stdout and stderr when reading JSON from any of the go commands.
Stdout will always be JSON.
But if an error happens, it will be printed to stderr, and probably stdout will be empty.
If the command exits with a non-zero status, use stderr and ignore stdout.

If the minor warning chatter here exposes tools that are not handling stdout/stderr correctly, that's unfortunate but not entirely terrible. Getting them fixed will make the tools more robust overall.