I am aware of controversy that exists about symbolic optimization mode in SMath.
Yet, I suppose, that in some (distant) future, the only existing mode should be symbolic, removing numerical "optimization" altogether.
Here is the rationale for that.
I suppose that the inconsistency between the results we have for numeric and symbolic modes in most cases is caused by existence of the two modes, that have their own computation algorithms for many functions, and must be kept in sync to provide the same final results. It's a kind of herculean load.
But the primary use of numerical mode is to get a number at some specific point of calculations. I see two places where it may happen:

When the result is requested using "=";

Somewhere in the middle of a calculation using eval().
Both may perfectly use symbolic engine to simplify their subexpressions as needed, and then finally request numeric result. So, there is no numeric "mode", just numeric result of some (limited) number of functions.
Here finally the clear distinction should be done between the "=" that returns number, and another one (requested multiple times, like ">") that corresponds to current symbolical result taken using Ctrl+.
Also, usual ":=" may be split to two: say, ":=" would mean shortsut for current ":=eval()", while something like "<" would mean "assign usual symbolic expression" (as in SS19).
If this removal of numeric mode will be performed, then any unwanted behaviour of symbolic engine will enjoy highestlevel attention, because (a) there will be no additional load to support another 50% of code doing the same differently, and (b) there will be no workaround available that lowers the severity of the problem. Any expression will have exactly one meaning, regardless of "mode", and results will be deterministic.
When taking symbolic result, any function would either return itself with symbolically processed arguments, of (if possible) a substitutional expression without itself if possible. Those functions that return themselves, will need to be able to also return numbers when getting final result.
Being able to control when one gets numerical result using eval() or (new numeric) := is enough for both optimization for speed or controlling over/underflows where it's possible.
Hope this sounds sane.