Well I'd say appropriate for the era and not "for a dubious reason".

I probably should have said "for lack of a sound reason". (Hmmm ... not sure if that's any different ;-)

It's just that, if the stringification provided an extra 2 decimal digits of precision, we would avoid having to look at rubbish diagnoses like this one (where the test fails but "got" and "expected" are reported as being the same):

C:\_32>perl -MTest::More -le "cmp_ok(0.14, '==', 1.4 / 10, '0.14 == 1.
+4/10'); done
_testing();"
not ok 1 - 0.14 == 1.4/10
#   Failed test '0.14 == 0.14'
#   at -e line 1.
#          got: 0.14
#     expected: 0.14
1..1
# Looks like you failed 1 test of 1.
[download]

IMO, if $x is an NV, then the condition "$x" == $x should always be true unless $x is NaN.
And that's the way it would be if doubles stringified to 17 digits of precision instead of the current 15 digits.
I would regard that as being a significant improvement for very little cost.
And we would then see that "got" is 0.14000000000000001 and "expected" is 0.13999999999999999 - which at least makes some sense.

It's still not ideal because the strings "0.14000000000000001" and "0.14" both assign to the same double - so why print out all of those extra digits ?
Python3 (and Raku, I believe) use as few digits as are needed and would report the double 0.14 as being "0.14" and not "0.14000000000000001".

I've implemented that Python3/Raku behaviour in Math::MPFR - though with a different algorithm and probably not as efficiently as Python3/Raku.

C:\>perl -MMath::MPFR="nvtoa" -le "print nvtoa(0.14);print nvtoa(1.4 /
+ 10);"
0.14
0.13999999999999999
[download]

Cheers,
Rob