Enabling by default the sum database broke a number of codebases that had altered the history of their codebases (either themselves or their dependencies). This should have been an opt in feature for this version.
Changing the way the pseudoversion behaves by expecting a correct date and specific sha length broke a larger number of codebases. This should have been a warning on this version and not cause the modules to fail.
There was one more change that I have wiped from my memory that broke athens. It has to do with how go now looks for a go.mod file in parent urls that caused athens to return a 500.
Overall spent about a week of swearing and trying to fix tools and deps. At the end gave up and moved back to 1.12.
Were you able to file any issues or explain to people what happened?
As for reporting the issues, it's something I assumed is common knowledge from the fact that any dep I had an issue with on the first day of 1.13 already had a bug filled.
Searching for `"invalid pseudo-version"` in github results in around 80 issues in different repositories that all have to do with go 1.13 and modules. 
Similarly a search for `golang "checksum mismatch"` will result in over 130 issues in regards to the sum db complaining about broken builds. 
There will be more that are not been correctly reported in github issues, and there will be false reports as well. But the repos that show up will have caused cascade issues.
We couldn't use golangci-lint for a couple of days before it was fixed. There is a limit to the amount of mod replaces I can live with before deciding it's not worth it.
Don't get me wrong. I do like mod, but I just think that for a language that prides itself on "backwards compatibility" it's doing a pretty poor job at keeping the same promise when mod is involved.
They got carried away with their own cleverness and forgot about the real world, shit happens.
The good news is they realized and and realigned with the community, which is awesome.
The most common source of dynamic linking is cgo, since CGO_ENABLED=1 is the default when not cross-compiling. For example, importing os/user will dynamically link against libc, unless you disable cgo or force statically linking with libc.
See https://github.com/golang/go/issues/26492 for more details. I think the purpose of the flag will be to force static linking in all edge cases, while not disabling cgo explicitly.
It's not clear what this new -static flag will do, likely automatically setup some of the linker static flags when compiling with CGO to statically link other dependencies and perhaps libc itself.
This has been my experience with Go. First a promise of everything being much simpler than the alternatives. Then, when we run into all sorts of confusion and caveats, an unapologetic disclaimer about why it's not simple and can't be, with a long exposition about Go's own internal limitations and the trade-offs they had to make.
Here it is mentioned in go1.13 release notes: https://golang.org/doc/go1.13#compiler
And GitHub says the commit is present in go1.13: https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8...
The problem is that if you don't set up your environment, set it up partially, or set it up incorrectly, some information about private repositories will be sent to Google. One solution is to use the envvar GONOSUMDB (either set from your shell's rc file or, preferably, from `go env`), thus instructing Go which domains it should not validate against the checksum database. Some individuals may not see this as an issue since private repos will fail to download via the default GOPROXY (`go get` should revert to "direct" mode) and nothing gets stored in the sumdb. However, Google does apparently log this information internally, and that's where the privacy issue arises.
For additional protection, you can set GOPROXY to your own self-hosted server, such as Athens, and configure it similarly so it'll reject such sumdb requests with a 403 to catch clients using only GOPROXY. But, you still have to remember to set GOPROXY (at a minimum), which means that if you or anyone in your organization forgets this bit, you're back where you started and you're probably sending information about your private repos to Google. Again.
Since this relies on envvars or the Go env stored in ~/.config/go/env (as an example) to set the behavior globally, you have to assume developers will correctly configuring every system they use. The GitHub issue is mostly centered on having a way to do this per-repository, and I honestly think that would have been a better solution, even combined with the `go env` settings.
Personally, it doesn't bother me too much, because an external immutable append-only log of commits in upstream packages will catch nefarious changes, so I think the benefits probably outweigh the privacy concerns until I see an adequate argument countering this. Regardless, I still have my `go env` set up to ignore my private repositories.
 The documentation says Google only logs the paths and doesn't publish them for private repositories their proxy fails to download. I thought I read somewhere that you can still use the sumdb for private repos, but it would instead send something like a SHA256 sum of the path for additional privacy. It might've been a proposal, and I can't find it now.
The only issue I'm still seeing is when having multiple go.mod files in the same workspace. I end up having to split projects with sub-modules in multiple workspaces in vscode and ignore the sub-modules on the main workspace. https://github.com/golang/go/issues/32394
0. allow embedding overlapping interfaces
1. len, cap to return untyped ints if constant
2. Remove SSLv3
3. Make TLS 1.3 opt-out
4. Automatically check and use vendored packages
5. Low-cost defers via inline code
6. Rewrite escape analysis
7. Expose the runtime's hasher
8. Add -static flag to go build
9. Store package metadata in build cache
[a] use go.sum hashes from all downloaded modules
[b] fail tests that run os.Exit(0)
[c] add testing.T.Deadline
[d] add regexp.SubexpIndex
[e] report failing test after a panic
[f] Rewrite the compiler's rulegen
What about providing a well thought out summary?
After all, I didn't post them here, someone else did :)
I personally think it's best to just follow the links if the title sounds interesting to you.
I did follow the links, however it is a bit tedious to then make a picture from the endless mountain of comments on each issue, hence the remark.
Clear scope, introduction of new features and demonstrations with examples (even of differences between versions)