Consider:

float const& f = 1.f;
int const i = (int&) f;

Per expr.cast/4 this should be considered as, in order:

• a const_­cast,
• a static_­cast,
• a static_­cast followed by a const_­cast,
• a reinterpret_­cast, or
• a reinterpret_­cast followed by a const_­cast,

Clearly a static_­cast<int const&> followed by a const_­cast<int&> is viable; it will construct a prvalue int initialized from the float (with value 1), materialize it, bind it to a const reference, cast away const, and then perform lvalue-to-rvalue conversion resulting in an int with value 1. 

However, all compilers that I have checked instead initialize i to 0x3f800000, indicating that they took the last option of reinterpret_­cast<int const&> followed by const_­cast<int&>. (If the UB offends you, consider changing int to unsigned char.)

This is somewhat related to CWG 909, involving conversion functions, which was closed NAD.

Should the Standard be changed to reflect implementation behavior, or should compiler vendors be persuaded to change their ways? I have a feeling that obeying the letter of the Standard here would silently break quite a lot of code, notwithstanding that such code would be pretty dubious already.