There appears to be some optimisation that is affecting the 4.0 constant.

Precision, not optimisation is the culprit:

Represent floating-point constants, including the parts of a complex constant, with a mantissa of at least 256 bits and a signed binary exponent of at least 16 bits.

After some good discussions on Slack (thanks everyone), this may be the correct albeit unexpected (to me and to a casual reader of the code): https://www.ardanlabs.com/blog/2014/04/introduction-to-numeric-constants-in-go.html

Constants Are Mathematically Exact
Regardless of the implementation, constants are always considered to be mathematically exact. This is something that makes constants in Go unique. This is not the case in other languages like C and C++.

@cznic, you are correct in that its precision but the issues is deeper than just the typical issues of floating point precision. it's related, it seems, to "[in] your issue all the computations are done at the "ideal constant" level with effectively unlimited precision, and then afterwards converted down to a float64" (credit @dgryski with that phrasing).

I'm left wondering about all the times I got this wrong. A typical use case for me would be using float64 constants in variable declarations à la:

x := Foo {
    Mean: (x0 + x1 + x3 + x4) / 4.0,
}

From my new understanding, that is not the same as

cnt := float64(4)
x := Foo {
    Mean: (x0 + x1 + x3 + x4) / cnt,
}

In this case, there are no other calculations to be done with the ideal 4 before it's needed as a float64 for the division, so it ends up being the same.

yeah, it was a bad example case as, in this case, the answers are the same. But introducing more complex math, like the original post, shows how that assumptions in that last example break down. Just one more thing to keep in mind. Your explanation about the "ideal 4" helps with dispelling the incorrect assumptions. Thanks.

Sounds like there's nothing to do here. Closing.