> none of the std libs are versioned, and I don't see any time soon a v2 for it. There is one precedent: the syscall package (https://golang.org/s/go1.4-syscal

> none of the std libs are versioned, and I don't see any time soon a v2 for it. There is one precedent: the syscall package (https://golang.org/s/go1.4-syscall https://golang.org/s/go1.4-syscall) It was deprecated and replaced with the versioned 'golang.org/x/sys/unix' package instead. The reason the syscall package was changed to an x package was because the x package could be versioned better, and because the stdlib package had to make breaking changes. I'm more or less just asking why we don't do the same thing for tls, http, and any other packages that, like syscall, have issues that cannot be fixed in a backwards compatible way. It seems like we've ended up making inconsistent decisions here, which ultimately lead to go programs breaking during go compiler upgrades... which is a thing that isn't supposed to happen.