I wouldn't call that ambiguity. While several shorthand notations use =, it is always clear from the context which one and only one is referring to (and if there are multiple that all of them agree).

This touches on another point that one sees much of in mathematics lectures but little in math lectures. Mathematical notation needs to be unambiguous but also facilitate communication and hence tends to be very terse. Thus when discussing addition on a finite field F_5, one usually starts defining equivalence classes [j] and an addition operator "+" and then says that [3]"+"[3]=[3+3]=[5+1]=[1] followed by a disclaimer like:

"We hence see that this notion is compatible with the previously defined one when identifying ... . Hence, if there is no possible confusion, we will simply write ..."

See also Tao's comments on rigor in mathematics: https://terrytao.wordpress.com/career-advice/theres-more-to-...

All notation can be made rigorous, if one wants to, but discussion is more concise if we let everybody do that by themselves.

Yeah, I think that's a good point and, I think, an important differecne between math notation and programming languages.

I think mathematicians thend to use a lot of "notational slang" or "ad-hoc syntactic sugar", if you will. This will make the notation often look imcomprehensible for people not familiar with the exact domain - however, there is usually a consistent meaning behind it. If one wanted, the notation could be "desugared" into a more rigid (but more verbose) form that expresses the same.

To take big-O-notation as an example, if you write something crazy-looking like

  x + 5 = O(x)

What you mean is

The function "f(x) := x + 5" is a member of the set of functions "O(x)".

Where "O(x)" is itself shorthand for a convoluted set expression.

Similarly, if you write

  x^3 + O(x)

You mean Take x cubed, then add the result of some function from the set O(x). (Whether you mean any function or one specific function is again context-dependent but usually it's made clear which of the two is meant.)

Contrast that with programming languages, where you often have a rigid syntax but higher-level semantics being quite fuzzy.

E.g., equals() and toString() in java are straight-forward to write but they can "mean" quite a lot of different things depending which kinds of objects you call them.

e.g., the "obvious" meaning of equals (value equality) works only with immutable value types - yet the method is defined on any kind of object. So it might also mean instance equality - or even entity equality if you deal with ORM proxies - or even wilder things...