At heart, this is really the same kind of thing that eventually prodded Python into adopting David Gay's burdensome ;-) code for correctly rounded double<->string I/O conversions.  We could similarly take on porting and maintaining KC Ng's fdlibm (an open source libm implementation Ng developed while at Sun - it doesn't guarantee correct rounding, but does guarantee max error strictly less than 1 ULP in all cases).

The tradeoffs are roughly similar.  For example, fdlibm is typically much slower than the platform C's libm, and most people using math libraries in anger are much keener about speed than avoiding noise results for inputs in ranges they never intend to use.  Perhaps surprisingly, fdlibm isn't "so slow" primarily because it's aiming at max 1 ULP error, but because it was coded to be as portable as possible.  Platform-specific libm implementations play every trick in the book (& invented many of the tricks in the book to begin with!) to squeeze out every cycle from the specific hardware they're intended to run on.  That makes "fast versus accurate versus portable" very much a "pick at most two" proposition for libm.