The Linux kernel is very different in this regard. Changes can be reverted easily. A change to the Go language will propagate quickly in it's users projects and probably stick with you forever.
Either they should say 'nope the BDFL accepts nothing significant except from the go core team' or they should change their ways. You can't have both.
Obviously other languages do manage the balance - eg. python, rust, so it's possible but I totally accept that given go's minimalism and opinionated approach they might not want that. But be honest about it.
And good luck reverting a released kernel buried on a server :) especially once users start relying on e.g. a syscall. You might find that it's not quite as different as you want it to be...
Even after migrating to a new executable format, Linux still has optional support to load the old format some 25 years later.
In comparison, Go does breaking changes from time to time, but it is also a much younger project. In general, comparing a language syntax with an api is hard to draw meaningful conclusions from.
Could you give some examples? I would say go has a very high standard of backwards compatibility (to a fault, even. Many good changes are not merged because they could break existing go programs.)
Only if nothing in userspace (the equivalent of "[Go]'s users projects") has started to depend on it. A OS kernel is perhaps slower than a programming language to see uptake of new features, but the dependencies are still there.