This is - excuse me - a pretty ridiculous claim, given the explicit design goals of go. https://talks.golang.org/2012/splash.article You might disagree, that their choices are furthering these design goals (I don't), but claiming that they focus on small-ish projects is just non-factual, most design decisions are driven by a focus on large (both in problem- and code size) projects.
> A lot of the problems are solved by "hit it until it compiles"
Neither do I want to need to fix compilation errors in software that I use, nor do I want my users to have to do it. This is not a solution to the problems at hand.
> The rest (adding methods -> you may collide with an interface which you didn't before) can probably be detected
No, they can't. From looking at your code you only get an outwards pointing import-arrow. There is no way for you to know which code actually relies on your API and in what way. You might, say, limit your guarantees to packages on godoc.org (which is indeed what I do in practice), but it's still hardly a solution to the problem.
> If you manage to limit most of your changes to "can be automatically changed / detected", you have a fair bit more freedom.
This is indeed the path I'm currently following; for every breaking change, provide an automatic fix. It still isn't an actual solution, though, just a halfway decent workaround. It especially doesn't work without https://github.com/golang/go/issues/18130 and a couple of other needed changes.
Luckily, go has immensely powerful tools to perform these kinds of rewrites (much more powerful than any other language I'm aware of) and I'm thus pretty optimistic that this will provide a good way forward soon (now that the need for gradual repair is officially recognized).