> As for operator overloading and language extensibility, I think most people would agree these are never really clear cut wins as they can add inordinate complexity in exchange for sometimes dubious value. It certainly makes some things look nicer (matrix and vector types for sure) but you can always use functions to get the same utility with less sugar.
Operator overloading to do what C++ did from the outset is a mistake. It looks flashy, but it buries land mines in the habits of your programmers. A programmer who is actually both shifting numbers and doing some other arithmetic operation may look at the code and wonder, "What is the precedence of these operations?" and having concluded that they don't remember, or at least, that their reviewers may not remember, though the compiler surely does, they'll add parentheses or re-factor. But if they've learned that shift is really some other operation concealed by overloading - they can be astonished when the compiler cheerfully applies that other operation with the precedence of a shift 'cos as far as the compiler is concerned that's still what it is.
But there definitely are uses (matrix addition for example) where just overloading an operator feels very sensible. I can see a strong case for == and != too if your language has that from the outset, it won't make sense to add it later.
So the trick is that a language should do this very sparingly and encourage programmers likewise, but I think that only makes it a feature to avoid entirely if you're very dedicated to having a small language, since overloading is nice but not necessary. Go maybe is in that category.