As I mentioned on StackOverflow, the literal in question appears to have been crafted to convert to the best possible 53-bit binary approximation to log(2) regardless of whether a compiler converts it to double precision (53 bits of precision) or to "double extended" (64 bits of precision).  In the latter case, the literal is such that the "extra" trailing 11 bits are all zeroes.

Since I doubt that's a potential issue anymore, even trying to document it would be confusing too ;-)

So while I'll defer to Mark, I'm inclined to just close this as "not a bug".  Math libraries typically bristle with code that's baffling to the uninitiated, and comments about things that don't matter can get in the way.  The only thing a libm developer cares about here is whether or not the literal converts to the best double approximation to log(2) - and it does.