Just take the operator overloading from Ceylon which has been designed to only allow mathematical use cases and harder to abuse for anything else. When you see an expression a + b it might not be two numbers but it will most likely be associative, distributive and commutative.

A lot of seemingly primitive Java syntax already expands to method calls: autoboxing, string conversions, string concatenation. Similarly, primitive arithmetic operators on unsigned integers could expand to calls to the corresponding Integer.{compare,divide,remainder,...}Unsigned methods. The compiler would turn these back into single machine instructions anyway. This would not need any new bytecode instructions.

Sure, though I do think that the currently existing rift between the primitive and object world should be healed first, to not leave behind another construct that will only be a backwards compatibility hindrance later.

(If I’m not mistaken, the existing unsigned functions already compile down to efficient machine code, so in the meanwhile that works)

There is exactly one good reason against operator overloading, and that’s operator<<. People are mostly sane otherwise and it’s a good thing to have.

Arbitrary overloading can be problematic, like !#< or whatever is quite hard to look up (scala, haskell), but I agree that implementing an interface/trait that will give you that syntactic sugar is mostly okay (like Rust, e.g. implements Add would give you + operator).

I remember working in some scala that used akka actors and seeing ! for the first time. Something like:

  actor ! someData

It was just an operator to send the data to the actor. A named function would have been so much better.