Well... I'm inclined to agree with you that your perl 5.8.6 result is incorrect. The decimal to binary conversion is incorrectly rounded  so worse than the usual representation error.
On my perl 5.10.0, using IEEE754 floating point doubles, your 0.99999999976716936 value is converted to the binary floating point value whose bit pattern is 0x3FEF_FFFF_FFDF_FFFF (or +0x1.F_FFFF_FFDF_FFFFp1, if you prefer). This appears to be the same as your 5.8.6 result.
Looking at that and the next two larger values I see:
0x3FEF_FFFF_FFDF_FFFF == 0.999999999767169245323827908578 (approx)
0x3FEF_FFFF_FFE0_0000 == 0.999999999767169356346130371093 (approx)
original value == 0.99999999976716936
0x3FEF_FFFF_FFE0_0001 == 0.999999999767169467368432833609 (approx)
What's odd about this is that the decimal to binary conversion is not 'correctly rounded' (I'm assuming roundtonearest as the only sensible rounding for the conversion)  0x3FEF_FFFF_FFE0_0000 is clearly a lot closer to the original 0.99999999976716936 than the values on either side of it !
I'm damned if I can see a good reason for getting this wrong. I note only that if you truncate the original value to 16 significant digits (ie to 0.9999999997671693) then 0x3FEF_FFFF_FFDF_FFFF is the correctly converted result.
I get the same results on 64bit Linux machine and 32bit Winders. So, either two different libraries have the same decimal to binary fault, or something in perl is wrong.
This is bad. IEEE754 requires the result of a conversion from binary to decimal and back to binary to be the original binary value, provided that at least 17 significant decimal digits are used (for doubles). I find that: 0x3FEF_FFFF_FFE0_0000 > 0.99999999976716936 > 0x3FEF_FFFF_FFDF_FFF
+F
However, wrong as this is, the general advice  not to depend on floating point results to be exactly equal to something  always applies.
