Tcl

And that result is technically correct in IEEE math, which is what Tcl is
exposing.

tcl_precision doesn't have to be touched for this unexpected result to
happen, simply:

% expr 1.1+2.2
3.3000000000000003

in a fresh tclsh

It appears this could be accommodated with
changes to Tcl_PrintDouble() and TclPrecTraceProc(),
but it is not clear at what expense. Keeping this
open at a low priority. Recommend either the
workaround already noted, or some other means
to attack whatever real problem is trying to be
addressed with the ::tcl_precision games.

A workaround would be to store the
constant values "1.1" and "2.2" in
variables so that compiling the expression
does not introduce the optimization.

set x 1.1; set y 2.2;
expr {$x + $y}

Starting in Tcl 8.5, the expression parser
detects constant expressions such as
" 1.1 + 2.2 " and notices that their value
is completely known at compile time, and
creates bytecode that simply pushes that
value on the stack. There is no runtime
computation at all.

This makes perfect sense using the 8.5
defaults where EIAS for double values
actually works.

For legacy support of scripts continuing
to use the ::tcl_precision variable against
advice, the assumption that a constant
expression will always compute the same
result fails.

Perhaps this can be fixed with some additional
detections of changes to the ::tcl_precision
variable triggering a reset of some compile epoch
to force recompile of the expressions?