I suggest adding the keyword "eq" as an alternative to the == token.
Why?
Especially "why?" because as you point out, the `eq` in `and_eq` already denotes a single equals sign. If you were going to add an English name for the == operator, "eqeq" would make more sense.
bitand= , bitor= , bitxor= seem more clear and consistent to me than and_eq, or_eq, xor_eq. The pain point is that bitand/bitor/binxor would have to become reserve words rather than just keywords. With that change, would there be any parsing ambiguities with these sequences of two tokens representing a single operator?
It's C++; there is always a parsing ambiguity.
Trying to make one lexical token out of two tokens is also a huge mess because it interacts with the Maximal Munch Rule. You'd have to invent a way to lex the sequence of characters `bitand==`. Today that means the two tokens `& ==`, but under your rule it seems like you'd want it to become `&= =`? How would you specify that, exactly?
Notice that under today's C++ lexing rules, `bitand&` is not a synonym for `&&`; it's a synonym for `& &`. I consider this a good thing.
–Arthur