expand and attempt to slightly clarify the FAQ on why 'go mod tidy' brings in indirect and test dependencies
diff --git a/Modules.md b/Modules.md
index 7b999cb..f8d094e 100644
--- a/Modules.md
+++ b/Modules.md
@@ -559,13 +559,15 @@
### Why does 'go mod tidy' record indirect and test dependencies in my 'go.mod'?
-In general, the modules system records precise dependency requirements in your `go.mod`. (For more details, see the [go.mod concepts](https://github.com/golang/go/wiki/Modules#gomod) section above or the [go.mod tip documentation](https://tip.golang.org/cmd/go/#hdr-The_go_mod_file)).
+The modules system records precise dependency requirements in your `go.mod`. (For more details, see the [go.mod concepts](https://github.com/golang/go/wiki/Modules#gomod) section above or the [go.mod tip documentation](https://tip.golang.org/cmd/go/#hdr-The_go_mod_file)).
-`go mod tidy` updates your current `go.mod` to include the transitive dependencies needed for tests in _all_ active modules, not just the main module: if a test fails (e.g., via `go test all`), we must know which dependencies were used in order to reproduce the failure.
+`go mod tidy` updates your current `go.mod` to include the dependencies needed for tests in your module — if a test fails, we must know which dependencies were used in order to reproduce the failure.
`go mod tidy` also ensures your current `go.mod` reflects the dependency requirements for all possible combinations of OS, architecture, and build tags (as described [here](https://github.com/golang/go/issues/25971#issuecomment-399091682)). In contrast, other commands like `go build` and `go test` only update `go.mod` to provide the packages imported by the requested packages under the current `GOOS`, `GOARCH`, and build tags (which is one reason `go mod tidy` might add requirements that were not added by `go build` or similar).
-If a dependency of your module does not itself have a `go.mod` (e.g., because the dependency has not yet opted in to modules itself), or if its `go.mod` file is missing one or more of its dependencies (e.g., because the module author did not run `go mod tidy`), then the missing transitive dependencies will be added to _your_ module's requirements, along with an `// indirect` comment to indicate that the dependency is not from a direct import within your module.
+If a dependency of your module does not itself have a `go.mod` (e.g., because the dependency has not yet opted in to modules itself), or if its `go.mod` file is missing one or more of its dependencies (e.g., because the module author did not run `go mod tidy`), then the missing transitive dependencies will be added to _your_ module's requirements, along with an `// indirect` comment to indicate that the dependency is not from a direct import within your module. Note that this means that any missing test dependencies from any of your direct or indirect dependencies will also be recorded in your `go.mod`. (An example where this is important: `go test all` runs the tests of all direct and indirect dependencies of your module, which is one way to validate that your current combination of versions work together. If a test fails in one of your dependencies when you run `go test all`, you want to have the precise dependency information recorded so that you have reproducible `go test all` behavior).
+
+In general, the behaviors described here are part of how modules provide 100% reproducible builds and tests by recording precise dependency information.
If you are curious why a particular module is showing up in your `go.mod`, you can run `go mod why -m <module>` to [answer](https://tip.golang.org/cmd/go/#hdr-Explain_why_packages_or_modules_are_needed) that question. Other useful tools for inspecting requirements and versions include `go mod graph` and `go list -m all`.
