It happens that 1.2000000000000002 is already the double precision floating point value nearest to the exact interpolation you submitted, as illustrated with Pharo smalltalk expression below (asTrueFraction means that floating point value is converted to a Fraction having exactly the same value)
(1 + ((0.4 asTrueFraction - 0.3333333333333333 asTrueFraction) * (2 - 1) / (0.6666666666666666 asTrueFraction - 0.3333333333333333 asTrueFraction))) asFloat
-> 1.2000000000000002.
Even if you evaluate the interpolation with exact arithmetic, we can do that by replacing asTrueFraction with asMinimalDecimalFraction (which get you the decimal number with minimal number of digits that will be rounded to the same Float):
0.4 asTrueFraction -> (3602879701896397/9007199254740992).
0.4 asMinimalDecimalFraction -> (2/5).
0.3333333333333333 asMinimalDecimalFraction -> (3333333333333333/10000000000000000).
0.6666666666666666 asMinimalDecimalFraction -> (3333333333333333/5000000000000000).
Then you get again the same result, see how it decompose:
(1 + ((0.4 asMinimalDecimalFraction - 0.3333333333333333 asMinimalDecimalFraction) * (2 - 1) / (0.6666666666666666 asMinimalDecimalFraction - 0.3333333333333333 asMinimalDecimalFraction)))
-> (4000000000000000/3333333333333333).
(4000000000000000/3333333333333333) asFloat -> 1.2000000000000002.
In other words, if you want a result in floating point, then 1.2000000000000002 is the best value.
I don't say that interpolation formula will always be exact as it is written, it can cumulate round off errors, but it already performs a decent job on your input data.
Change the test rather than the formula, and insert explicit accuracy requirements.