add three new detailed FAQs on +incompatible, "minimal module awareness", and importing non-module packages. (Still a bit rough; will hopefully polish later with fresh eyes).
diff --git a/Modules.md b/Modules.md
index 36612af..a7b3d74 100644
--- a/Modules.md
+++ b/Modules.md
@@ -646,6 +646,111 @@
Please see the question "Why are major versions v0, v1 omitted from import paths?" in the earlier [FAQ from the official proposal discussion](https://github.com/golang/go/issues/24301#issuecomment-371228664).
+### Can a module consume a package that has not opted in to modules?
+
+Yes.
+
+If a repository has not opted in to modules but has been tagged with valid [semver](https://semver.org) tags (including the required leading `v`), then those semver tags can be used in a `go get`, and a corresponding semver version will be record in the importing module's `go.mod` file. If the repository does not have any valid semver tags, then the repository's version will be recorded with a ["pseudo-version"](https://golang.org/cmd/go/#hdr-Pseudo_versions) such as ` v0.0.0-20171006230638-a6e239ea1c69` (which includes a timestamp and a commit hash, and which are designed to allow a total ordering across versions recored in `go.mod` and to make it easier to reason about which recorded versions are "later" than another recorded version).
+
+For example, if the latest version of package `foo` is tagged `v1.2.3` but `foo` has not itself opted in to modules, then running `go get foo` or `go get foo@v1.2.3` from inside module M will be recorded in module M's `go.mod` file as:
+
+```
+require foo v1.2.3
+```
+
+The `go` tool will also use available semver tags for a non-module package in additional workflows (such as `go list -u=patch`, which upgrades the dependencies of a module to available patch releases, or `go list -u -m all`, which shows available upgrades, etc.).
+
+Please see the next FAQs for additional details related to v2+ packages that have not opted in to modules.
+
+### Can a module consume a v2+ package that has not opted into modules? What does '+incompatible' mean?
+
+Yes, a module can import a v2+ package that has not opted into modules, and if the imported valid v2+ package has a valid [semver](semver.org) tag, it will be recorded with an `+incompatible` suffix.
+
+**Additional Details**
+
+Before proceeding, please first be familiar with the material in the ["Semantic Import Versioning"](https://github.com/golang/go/wiki/Modules#semantic-import-versioning) section above.
+
+For example, suppose:
+* `oldpackage` is a package that predates the introduction of modules
+* `oldpackage` has never opted in to modules (and hence does not have a `go.mod` itself)
+* `oldpackage` has a valid semver tag `v3.0.1`, which is its latest tag
+
+In this case, running for example `go get oldpackage@latest` from inside module M will record the following in module M's `go.mod` file:
+
+```
+require oldpackage v3.0.1+incompatible
+```
+
+Note that there is no `/v3` used at the end of `oldpackage` in the `go get` command above or in the recorded `require` directive -- using `/vN` in module paths and import paths is a feature of Semantic Import Versioning, and `oldpackage` has not signaled its acceptance and understanding of Semantic Import Versioning given `oldpackage` has not opted into modules by having a `go.mod` file within `oldpackage` itself. In other words, even though `oldpackage` has a [semver](https://semver.org) tag of `v3.0.1`, `oldpackage` is not granted the rights and resposibilites of _Semantic Import Versioning_ (such as using `/vN` in import paths) because `oldpackage` has not yet stated its desire to do so.
+
+The `+incompatible` suffix indicates that the `v3.0.1` version of `oldpackage` has not actively opted in to modules, and hence the `v3.0.1` version of `oldpackage` is assumed to _not_ understand Semantic Import Versioning or how to use major versions in import paths. Therefore, when operating in [module mode](https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior), the `go` tool will treat the non-module `v3.0.1` version of `oldpackage` as an (incompatible) extension of the v1 version series of `oldpackage` and assume that the `v3.0.1` version of `oldpackage` has no awareness of Semantic Import Versioning, and the `+incompatible` suffix is an indication that the `go` tool is doing so.
+
+The fact that the the `v3.0.1` version of `oldpackage` is considered to be part of the v1 release series according to Semantic Import Versioning means for example that versions `v1.0.0`, `v2.0.0`, and `v3.0.1` are all always imported using the same import path:
+
+```
+import "oldpackage"
+```
+
+Note again that there is no `/v3` used at the end of `oldpackage`.
+
+In general, packages with different import paths are different packages. In this example, given versions `v1.0.0`, `v2.0.0`, and `v3.0.1` of `oldpackage` would all be imported using the same import path, they are therefore treated by a build as the same package (again because `oldpackge` has not yet opted in to Semantic Import Versioning), with a single copy of `oldpackage` ending up in any given build. (The version used will be the semantically highest of the versions listed in any `require` directives; see ["Version Selection"](https://github.com/golang/go/wiki/Modules#version-selection)).
+
+If we suppose that later a new `v4.0.0` release of `oldpackage` is created that adopts modules and hence contains a `go.mod` file, that is the signal that `oldpackage` now understands the rights and resposibilites of Semantic Import Versioning, and hence a module-based consumer would now import using `/v4` in the import path:
+
+```
+import "oldpackage/v4"
+```
+
+and the version would be recorded as:
+
+```
+require oldpackage/v4 v4.0.0
+```
+
+`oldpackage/v4` is now a different import path than `oldpackage`, and hence a different package. Two copies (one for each import path) would end up in a module-aware build if some consumers in the build have `import "oldpackage/v4"` while other consumers in the same build have `import "oldpackage"`. This is desirable as part of the strategy to allow gradual adoption of modules. In addition, even after modules are out of their current transitional phase, this behavior is also desirable to allow gradual code evolution over time with different consumers upgrading at different rates to newer versions (e.g., allowing different consumers in a large build to choose to upgrade at different rates from `oldpackage/v4` to some future `oldpackage/v5`).
+
+### How are v2+ modules treated in a build if modules support is not enabled? How does "minimal module compatibility" work in 1.9.7+, 1.10.3+, and 1.11?
+
+When considering older Go versions or Go code that has not yet opted in to modules, Semantic Import Versioning has significant backwards compatibility implications related to v2+ modules.
+
+As described in the ["Semantic Import Versioning"](https://github.com/golang/go/wiki/Modules#semantic-import-versioning) section above:
+* a module that is version v2 or higher must include a `/vN` in its own module path declared in its `go.mod`.
+* a module-based consumer (that is, code that has opted in to modules) must include a `/vN` in the import path to import a v2+ module.
+
+However, the ecosystem is expected to proceed at varying paces of adoption for modules and Semantic Import Versioning.
+
+As described in more detail in the ["How to Release a v2+ Module"](https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher) section, in the "Major Subdirectory" approach, the author of a v2+ module creates subdirectories such as `mymodule/v2` or `mymodule/v3` and moves or copies the approriate packages underneath those subdirectories. This means the traditional import path logic (even in older Go releases such as Go 1.8 or 1.7) will find the appropriate packages upon seeing an import statement such as `import "mymodule/v2/mypkg"`. Hence, packages residing in a "Major Subdirectory" v2+ module will be found and used even if modules support is not enabled (whether that is because you are running Go 1.11 and have not enabled modules, or because you are running a older version like Go 1.7, 1.8, 1.9 or 1.10 that does not have full module support). Please see the ["How to Release a v2+ Module"](https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher) section for more details on the "Major Subdirectory" approach.
+
+The remainder of this FAQ is focused on the "Major Branch" approach described in the ["How to Release a v2+ Module"](https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher) section. In the "Major Branch" approach, no `/vN` subdirectories are created and instead the module version information is communicated by the `go.mod` file and by applying semver tags to commits (which often will be on `master`, but could be on different branches).
+
+In order to help during the current transitional period, "minimal module compatibility" was [introduced](https://go-review.googlesource.com/c/go/+/109340) to Go 1.11 to provide greater compatibility for Go code that has not yet opted in to modules, and that "minimal module compatibility" was also backported to Go 1.9.7 and 1.10.3 (where those versions are effectively always operating with full module mode disabled given those older Go versions do not have full module support).
+
+"Minimal module compatibility" provides backwards compatibility for v2+ modules in GOPATH mode without relying on the module author creating `/vN` subdirectories (and hence "minimal module compatibility" provides an alternative to the ["Major Subdirectory"](https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher) approach to backwards compatibility).
+
+The primary goals of "minimal module compatibility" are:
+
+1. Allow older Go versions 1.9.7+ and 1.10.3+ to be able to more easily compile modules that are using Semantic Import Versioning with `/vN` in import paths, and provide that same behavior when [module mode](https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior) is disabled in Go 1.11.
+
+2. Allow old code to be able to consume a v2+ module without requiring that old consumer code to immediately change to using a new `/vN` import path when consuming a v2+ module.
+
+**Additional Details – "Minimal Module Compatibility"**
+
+"Minimal module compatibility" only takes effect when full [module mode](https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior) is disabled for the `go` tool, such as if you have set `GO111MODULE=off` in Go 1.11, or are using Go versions 1.9.7+ or 1.10.3+.
+
+The following bullets describe in more detail the case when a v2+ module author has _not_ created `/v2` or `/vN` subdirectories and you are instead relying on the "minimal module compatibility" mechanism in Go 1.9.7+, 1.10.3+ and 1.11:
+
+* A package that has _not_ opted in to modules would _not_ include the major version in the import path for any imported v2+ modules.
+* In contrast, a package that _has_ opted in to modules _must_ include the major version in the import path to import any v2+ modules (in order to properly import a v2+ module when the `go` tool is operating in full module mode).
+ * If a package has opted in to modules, but does not include the major version in the import path when importing a v2+ modules, it will not import a v2+ version of that module when the `go` tool is operating in full module mode. (A package that has opted in to modules is assumed to "speak" Semantic Import Versioning. If `foo` is a module with v2+ versions, then under Semantic Import Versioning saying `import "foo"` means import the v1 Semantic Import Versioning series of `foo`).
+* The mechanism used to implement "minimal module compatibility" is intentionally very narrow:
+ * The entirety of the logic is – when operating in GOPATH mode, an unresolvable import statement containing a `/vN` will be tried again after removing the `/vN` if the import statement is inside code that has opted in to modules (that is, import statements in `.go` files within a tree with a valid `go.mod` file).
+ * The net effect is that an import statement such as `import "foo/v2"` within code that lives inside of a module will still compile correctly in GOPATH mode in 1.9.7+, 1.10.3+ and 1.11, and it will resolve as if it said `import "foo"` (without the `/v2`), which means it will use the version of `foo` that resides in your GOPATH without being confused by the extra `/v2`.
+ * It does not affect anything else, including it does not the affect paths used in the `go` command line (such as arguments to `go get` or `go list`).
+* Note there is therefore more than one valid import path for a v2+ module used in GOPATH mode under "minimal module compatibility", all of which resolve to the pre-modules import path (that is, the import path without a `/vN`).
+ * Under the modules system, this is the sole exception to the rule "packages with different import paths are different packages" (along with perhaps a caveat around the legacy possibility of multiple `vendor` directories if not in full module mode).
+ * For example, when operating in GOPATH mode, `import "foo/v2"` in module-based code resolves to the same code residing in your GOPATH as `import "foo"`, and the build ends up with one copy of `foo` – in particular, whatever version is on disk in GOPATH. This behavior is for backwards compatibility, and this allows module-based code with `import "foo/v2"` to compile even in GOPATH mode in 1.9.7+, 1.10.3+ and 1.11.
+ * In contrast, when the `go` tool is operating in full module mode, different import paths always resolve to different packages (for example, if `foo` is a v2+ module, then `import "foo"` is asking for a v1 version of `foo` vs. `import "foo/v2"` is asking for a v2 version of `foo`).
+
### What are some implications of tagging my project with major version v0, v1, or making breaking changes with v2+?
In response to a comment about *"k8s does minor releases but changes the Go API in each minor release"*, Russ Cox made the following [response](https://github.com/kubernetes/kubernetes/pull/65683#issuecomment-403705882) that highlights some implications for picking v0, v1, vs. frequently making breaking changes with v2, v3, v4, etc. with your project:
