Operators are not special here. What you are saying is basically "don't claim to implement the interface if you didn't implement it".
This exact problem exists widely in, for example, Java. How often do you see a Java object where someone overrode equals() but not hashCode()? I've seen that problem vastly more often than anyone doing something crazy with operators.
Not quite true, the language could implement checked over- or under-flows (I believe Swift does)
I am one of the apparently about ten people who thinks that should be the universal default. The vast bulk of people disagree, and I was trying not to poke the sleeping dog. :)
There's a handful of us, a handful!
FWIW Rust checks for overflow in debug mode, and while that's elided by default when compiling with optimisations it can be re-enabled with a -Z flag:
> rustc test.rs
> ./test
thread '<main>' panicked at 'arithmetic operation overflowed', test.rs:4
> rustc -O test.rs
> ./test
Overflowed!
> rustc -O -Z force-overflow-checks=on test.rs
> ./test
thread '<main>' panicked at 'arithmetic operation overflowed', test.rs:4
Operator overloading works best when being used in domains where the original constraints hold; for instance, adding a matrix to a matrix is mostly the same as adding two numbers, though if your type system can't enforce that the matrices are the same size at compile time, you still added the ability for + to throw an exception, which it will never do with ints. Operator overloading got its bad name from cases where people were overloading the operators to do something entirely unlike what the original operator did, causing a mismatch between the user's expectations and what it actually did and therefore bugs.
Operator overloading isn't really "right" or "wrong" per se, but it's probably a bad idea for anything that isn't able to fully implement the contract of the operator, including "associativity", "no side effects", whether exceptions can be thrown, etc.
If you read carefully, you'll generally see operator overloading arguments have two groups talking past each other, one cursing things like C++ streams that basically overloaded the operators in a meaningless way for nominal convenience that causes a lot of long-term headaches, and the other praising the benefits of overloading for math, since math is the big case where it works correctly.
Back on topic, Go correctly does not have operator overloading because Go's authors, as near as I can tell, have no intention of Go being good for mathematics.