The D programming language takes the (so far as I know) unique approach that the implementation is allowed to evaluate expressions in the highest precision it wants to - the different floating point data types only represent storage formats.
The idea is that algorithms should be designed with a minimum required precision, but no maximum, and should not fail if higher precision is used.
The .NET CLI takes the same approach. Any implementation is allowed to use a higher precision if it wants. The stated rational is for performance:
"This design allows the CLI to choose a platform-specific high-performance representation for floating-point numbers until they are placed in storage locations. For example, it might be able to leave floating-point variables in hardware registers that provide more precision than a user has requested. "
Indeed most optimizing compilers (including C and Fortran) maintain full hardware precision in intermediate results. It's one of the reasons that debug and release versions of the same numerical code often give different results.
That seems a bit terrible. Now it's D so it's not like it's a real problem but: if I went from one "standards compliant" implementation to another and suddenly my numerical code started being shit because it turns out my first compiler was silently more precise... there would be much wailing and gnashing of teeth.
The vagaries of floating point mean this "terrible" scenario essentially happens already. For example, a "double" variable isn't the same from one machine to another. And debug vs release versions of the same numerical code, built with the same compiler and run on the same machine, can arrive at different answers. These things lead to much gnashing of teeth in the scientific programming community already.
I have a numerical code that I cross-compile with gcc -O0, gcc -O3, clang, icc, and MS Visual C, all on the same machine. Each version can give slightly different results. The fact that they don't give wildly different results is mainly down to the stability (in the ODE sense) of the problems run. Unstable problems would definitely give different results.
That 'other standards compliant compiler' need not be the one with higher precision.
Also, it might have higher precision in most cases but just not in that case where your code needs it most.
Real-world examples are x86 compilers that use the 80-bit floating point registers for intermediates, but flush them to 64-bit results (sounds stupid, but it is not; flushing typically is done to the bytes that hold the result variable). There, the register allocation algorithm used by the compiler can be the determiner of which operation sequences get done in 80 and which in 64 bits.
The idea is that algorithms should be designed with a minimum required precision, but no maximum, and should not fail if higher precision is used.
I think this rule serves very well.