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).
add comment in 'Releasing Modules (v2 or Higher)' section regarding advice to increment major version when first adopting modules for a pre-existing v2+ package
provide a slightly longer explanation of the 'tools.go' approach along with a pointer to a "Go Modules by Example" walkthrough; also fix an FAQ link that someone broke, and swap ordering of two FAQs
mention in "How to Define a Module" that 'go mod init' does not add '/vN' to the dependencies listed in 'go.mod', or at least, it does not always do so.
update the 'go.mod' section, including provide a simple tree showing an example on-disk structure; additional minor improvement to 'Semantic Import Versioning' section
mention again that 'go.sum' should be checked in in the 'go.sum' FAQ (this continues to come up); additional minor improvements to the 'How to Define a Module' section
remote pre-beta3 syntax; adjust the table of contents to make the overall structure of the page clearer; introduce sub-sections for the now long-ish FAQ section; re-order sections
move the more complex steps for v2+ modules out of the 'Semantic import versioning' concepts section and into the 'How to prepare a release section'; make more explicit; refer directly to github.com/marwan-at-work/mod as an option for automating the steps for v2+ modules
one more sentence for `go.sum` FAQ stating `go.sum` captures everything in a build; also move the other 'go.mod' FAQ to be immediately after the go.mod/go.sum FAQs
update 'go mod tidy' FAQ (provide a little more context up front; re-order paragraphs; tweak text); add FAQ on whether or not 'go.sum' is a lock file and why 'go.sum' retains information after you stop using something
explicitly mention less sensitive to change to avoid the version on the left side of a replace statement; add pointer to `replace` FAQ from section on go.mod
take a stab at simplifying the `go get` fails outside of modules FAQ, and outline a couple more options, including a script put together by rogpeppe; also slightly simplify the tool status FAQ
mention that 1.11 was also updated to understand the use of SIV by code that has opted in to modules (even if module awareness is disabled, for example)
mention explicitly that `go.mod` provides enough information for reproducible builds without `go.sum` being a lock file. (Some people think of `go.sum` as a lock file).
update MVS example, including more explicitly work in the phrase "100% reproducible builds"; also draw stronger contrast between `go mod tidy` vs. `go build`; move proxy discussion into FAQ (prior level of detail didn't really belong up front)
flip order of explanation for why `go mod tidy` is useful, and provide a more targeted pointer to explanation how `go mod tidy` reflects all possible build tags/OS/architecture combinations
add a v2+ example to the first go.mod example; remove sentence about ability to quote module paths (given its usefulness is more a corner case that doesn't need to be covered so early in introductory material)
add 3 more FAQs on: why `go get example.com/cmd` fails with error `cannot find main module` when run outside of module; how to track tool dependencies of a specific module; and summarize the GO111MODULE/GOPATH behavior
expand the 'Semantic Import Versioning' section, including quote the old versioning advice from the FAQ, quote the import compatibility rule, attempt to tie them together
include reference to pseudo-versions in module query introduction; use friendlier example modules for the intro `go.mod` shown and clean up related text
mention option of a `v2.0.0` release on master along with the subsequent suggestion for a v1 branch (option outlined in official proposal FAQ); also provide an explicit pointer back to this v2+ discussion from the 'Releasing a module' section; adjust the older "still in flux" comment regarding v2+ modules
in 'Semantic import versioning' concepts section: include more explicit pointer to semantic import version section of tip documentation; mention the actual older versions 1.9.7 and 1.10.3 that now have minimal module awareness; mention that the '/v2' subdirectory approach allows for compatibility with even older Go versions and make the description a bit more specific
add a recommendation to typically check in `go.sum` (e.g., see https://twitter.com/FiloSottile/status/1029404663358087173); also mention that `go.sum` is not a traditional lock file, which is a question that comes up somewhat frequently
add pointer to thread discussing adding betas to CI; also include pointers to sample Travis config for go11.1beta3, and a sample CircleCI config for a matrix build in CircleCI 2.0 (though would like to find a better go-specific CircleCI example)
make it slightly clearer that the discussion around possible additional forms of declarations of incompatibilities are only possible avenues / not set in stone
remove text that asserted v1 and v2 of a module are different modules (not sure that's true, but in any event likely clearer to talk about different packages; was hold-over text from several months ago when this was the 'vgo user guide' wiki)
attempt to simplify the intro concepts discussion on modules, go.mod, with more pointers to encourage people to read the proposal and official doc; also move the older (and perhaps somewhat confusing to a newcomer) v2+ discussion to live in the semantic versioning section. (Overall, much of text touched here was hold-over from several months ago when this was the 'vgo user guide' wiki)
add faq on what do when project has historically made breaking changes without bumping the major version (answer currently references recent k8s comment from rsc)
added Table of Contents (slightly odd placement of TOC in an attempt to keep 'Current Status' section or at least its heading above the fold); tweaked my list of post-vgo-proposal changes
flip the order of the two options for creating a /v2+ module. (I've seen predictions that the /v2+ directory-based approach will be less common, though I guess we'll see what the future brings)
small tweak to 'full module path' examples to make it slightly easier to scan (e.g., changed 'pkg1' -> 'pkg' given there are already many numbers in the example)
moved older text about allowing a v1 module to be implemented in terms of its v2 replacement to the 'Major Versions' section, and some small related edits to 'Major Versions' section
briefly introduce MVS, but point to the proposal and initial vgo blog series for details; mention the latest version is selected for new direct dependencies; add some additional pointers; remove the 'for now' from the section on semantic import versioning (I'm guessing that was written a while ago); other minor text cleanup
