It's just an API kind of thing. If a function / constant / var / type was available and is not anymore, it's a breaking change. It's an objective measure, there is nothing left to subjectivity.
Now, of course a bug fix is going to "break" things if your code relied on the bogus behavior. An updated algorithm can also break things (I maintain a SAT solver, whenever I update the underlying algorithm, even if it's way faster on average, in some limited cases it can make one very specific problem way slower to solve, which can have bad consequences). But as it has no consequence on the API part of things, it's not a major change in semver's meaning.
There are far more extensive possibilities than what you export - almost every change can be breaking change, often without the producer knowing about it. This is why nobody uses strict semver in practice.
The parent commenter is correct in the sense that API changes can be, and should be, automatically checked for server.. you're just saying that doing that still does not guarantee there's no breaking changes because, besides API changes, there's also semantic changes, and those are difficult, perhaps impossible, to automatically check.
Well both, because there is a disconnect between the two.
Strict semver (as proposed by go mod) - any breaking change means a new major version, and a 'new package' at a new import url. This means older users are left behind unless they explicitly upgrade and producers are encouraged to make breaking changes because it is easy for them. At present there are no measures to alert consumers to upgrade or communicate what the changes are. This doesn't reflect current practice even in the Go project itself (at 1.x despite small breaking changes/deprecations).
Loose semver (as used in the real world) - package identity is constant, minor breakage happens at every patch level and the level of breakage is negotiated between producers and consumers at the package level. semver is used to signal changes (major - big changes, possible breakage; minor - small changes, less breakage; patch - tiny changes, possible breakage to that area). Note major versions usually are used for big changes, not just breaking changes and big changes can be just as painful for consumers (e.g. in v3 we're introducing a new api for payments, start using it, the old one is still there but will go away soon in v3.1). Usually package management systems provide mechanisms to help that negotiation (automatic upgrades within minor/patch on the assumption breakage is minimal).
There are good reasons for the current go mod defaults (simple dependency resolution, simple migration between versions), but they do ignore real-world usage IMO and will lead to a bit of pain without some further work to resolve those contradictions.
It's just an API kind of thing. If a function / constant / var / type was available and is not anymore, it's a breaking change. It's an objective measure, there is nothing left to subjectivity.
Now, of course a bug fix is going to "break" things if your code relied on the bogus behavior. An updated algorithm can also break things (I maintain a SAT solver, whenever I update the underlying algorithm, even if it's way faster on average, in some limited cases it can make one very specific problem way slower to solve, which can have bad consequences). But as it has no consequence on the API part of things, it's not a major change in semver's meaning.