The difference is convention. One is conventional, it does what you know and expect. The other is non conventional, and adds completely new meaning to the operator.
I’m not saying overloading in general is bad. But that overloading the semantics is bad. In fact; actively harmful. Adding a bitwise & for bit sequences and bit vectors other than Int is a non-issue as long as the semantics are respected.
I’m not speaking of using names to encode type information, but again to encode semantics. This whole discussion is about readability, and maintainability of code. Names matter. In fact, the Swift guidelines spends several paragraphs on naming.
You’re right that naming is orthogonal to operator usage, but when the operator has several competing and non-compatible semantics, it undermines readability to also use non-descriptive names.
One could argue that it’s clear which overload is used in let two = evenNumbers & primeNumbers and which is used in let clipped = image & mask. But when a reader reads let c = a & c, there’s no way to know, without scanning up and down the screen, or using your IDE for assistance.
You can read that as an argument for your overload, but against your code sample. Using good names can certainly help make it obvious what’s going on, which makes the pain of overloaded operators more acceptable. However, the opposite is also true: When overloading operators with new meaning, you have to be more explicit around your operators, and you can’t get away with letting your operator communicate intent for you.