I also ran into issues with quadmath builds.

Thanks for the excellent info.
In specifying NV_DIG as the second arg handed to quadmath_snprintf() I had made a mistake. It's quite possible that more than 33 characters need to be written to enc->cur.
I'll switch to enc->end - enc->cur.

It seems to me that there's no reason to assume that the user wants 33 digits of precision just because perl's nvtype is __float128, but "33" is probably as good an assumption as anything else.
Anyone wanting just "double" precision values could alter the "%.33Qg" to "%.15Qg" and rebuild and reinstall the module. (For the same outputs as a "long double" build of perl, you'd specify "%.18Qg".)
I think those various options work fine - though I haven't rigorously tested them.

Your rewrite of the test looks fine to me, too.
The failure of the test is just a quirk of the way perl displays that edge case value:

>perl -le "print 1.01e30;"
1010000000000000000000000000000
<c>
Similar things happen with long double values:
<c>
>perl -le "print 1.01e17;"
101000000000000000
[download]

and with doubles, too:

perl -le "print 1.01e14"
101000000000000
[download]

Cheers,
Rob