You may insist on this, but the fact that it does not exist in any convenient form leaches strength from your argument.
In fact harmless overflow is extremely common, and relied upon. Trapping by default, while it would would call attention to some bugs, would also turn many working programs into crashing programs.
Saturating arithmetic would sometimes produce better results.
I believe that you confuse integer overflow, which applies only to the signed integers of C/C++ with the arithmetic operations on modular numbers, which are improperly called "unsigned integers" in C/C++.
When computing with modular numbers, you rely on the exact modular operations. That is not overflow.
There exists no "harmless overflow". The overflow of "signed integers" is an undefined operation in the C/C++ standard.
The actual behavior of integer overflow is determined by the compiling options. With any decent compiler, you may choose between 3 behaviors: trap on overflow, which aborts the program unless it is caught, display an error message and continue the execution with an undefined result of the overflown operation (typically with the purpose of also seeing other error mesages), or ignore the overflow and continue the execution with an undefined result of the overflown operation (the default option).
Relying in any way upon what happens on overflows (of "signed integers"), when choosing a compiling option that does not trap on overflow, is an unacceptable mistake, because what the program does is unpredictable.
Relying on what modular arithmetic does with "unsigned numbers" is correct, except that in most cases they are not really used as modular numbers, but the programmers expect that modular reduction will never happen. When it happens and it was not expected, it may cause similar problems like overflows, even if the result could have been predicted.
You are right that saturating arithmetic is the main alternative to trapping on overflow. It can be used in the same way as infinities are used with floating-point numbers when the overflow exception is masked.
Unfortunately, saturating arithmetic does not exist in the standard C/C++ languages. Therefore in C/C++ you may choose only between trapping on overflow and dangerous undefined behavior.
Saturating on overflow as bad as the 2s complement wraparound on unsigned if you were not expecting/relying on it. C lacks a type where unsigned overflow is an error or UB. Having it UB is acceptable because then you can choose a compiler option (-ftrapv) that traps it. But, I have heard this is unreliable, e.g. what happens if the overflow happens in library code?
Ada does this correctly, and lets you choose between exception and wraparound. UB is not an option in the language spec, though you can turn off the checks as an optimization option in GNAT, or maybe turn it off at specific lines of code with a pragma.
In fact harmless overflow is extremely common, and relied upon. Trapping by default, while it would would call attention to some bugs, would also turn many working programs into crashing programs.
Saturating arithmetic would sometimes produce better results.