We can document this for Go 1.10 but I don't think we should change it. That would unnecessarily break existing tools consuming this. For instance, encoding/json.Decoder will consume multiple concatenated JSON objects.

Another way of describing "multiple concatenated JSON documents" is a that it's a JSON stream of objects. They are easy to parse.

For instance, encoding/json.Decoder will consume multiple concatenated JSON objects.

I was not aware of this -- there isn't really an issue, then, if it's simple to decode into []type from a concatenated document.

@stevekuznetsov, see https://godoc.org/encoding/json#example-Decoder for an example.

Right on, using that encoding/json.Decoder.More() pattern now. Feel free to close this -- the issue here was really that I thought it was going to be super difficult to get an API into the really awesome output of go list -- while this is still the case (os.Exec + json.Decoder is not the best), it's not not totally impossible. I would love to see the functions that resolve packages recursively be exported from some other utility package, but I understand to some extent why the backing logic for go list is private.

@stevekuznetsov There is github.com/kisielk/gotool which contains an exported copy of the Go tool's resolution of package paths (... and so on)