It also looks like you may have found a better way to do this that does not require determining the FP type in advance?

Reading the bytes works well for comparing NV values, but unfortunately List::Util::uniqnum() also needs to be able to recognize that (eg) the IV "42" and the NV "42.0" are the same value.
Unfortunately that breaks down when one starts reading the bytes of the NV ;-)

You can't quite avoid determining the FP type, anyway. For a 16-byte extended precision long double I don't think it's wise to assume that 2 identical NVs would necessarily have the same 6 unused bytes.
For that type I decided I should locate the unused bytes and not read them. That additionally required that endianness be established (which is quite easy, courtesy of $Config{byteorder}).

So I'll just go with the original solution. As regards what to do regarding the DoubleDouble, I'm trying to establish whether the deplorable state of stringification that I'm seeing is typical ... or whether it's just *my* system that's suffering.
If mine is typical, then I'll just do "%.36" NVgf for the DoubleDouble. But if recent improvements have been made then I might try something smarter.
No-one (apart from me) uses DoubleDouble builds of perl anyway, and I haven't been able to find a failure using "%.36" NVgf so I'm not all that committed to spending too much time on it.

Cheers,
Rob