Very clever.

Fixed

Creating a class usable in mathematical calculations is a duplicate to many katas.

unnecessary breaks

It used to be a problem on old FPUs with 80-bit ALU registers, where just moving a number between 64-bit memory location and 80-bit ALU registers back and forth could change its least significant bits

Other than there's obvious rounding when moving an 80-bit float to a 64-bit float and possibly some weirdness with denormalized numbers, I don't know what could happen that woudn't have been considered a hardware bug.
There can be unexpected differences if intermediate results are more precise than expected, but it's not relevant here.
There are some instructions that have limited precision by definition (reciprocal square root), not relevant here either.

• Reason 1: it was easier to copy/paste this way :)
• Reason 2: actually I never invested enough effort into finding out if an IEEE-754 number can come unchanged out of operations which logically should not modify it. It used to be a problem on old FPUs with 80-bit ALU registers, where just moving a number between 64-bit memory location and 80-bit ALU registers back and forth could change its least significant bits, and it just stuck to me without actually verifying if it's a real problem today, or not. Or maybe I just got things wrong from beginning?

Expect(Sum([]float64{n})).To(BeNumerically("~", n, 1e-4))

Why "~"?.. There is only one number to sum.

Superseded by this fork: https://www.codewars.com/kumite/5d4da226feb62f00153941e3?sel=5fd58299148bfb0022a19ecc.

Note the "Solution setup" contains invalid Go code - look at how every solution modifies it.

"already approved some time ago"

Nice solution! You can omit 0 in l[0:i] by the way

Hmmm... I don't know enough about Go to fix it, sorry.

Not fixed. Try running a solution that sums in the reversed order. rand.Float64() generates a random 53-bit significand.

(duplicate comment)

I think fixed.