Not sure that anyone here is particularly interested in this, but I'll mention it anyway that, as of the release (on 20.01.2021) of perl-5.33.6, it's possible to build perl on MS Windows with an NV type of __float128.
And it has become a little easier in 5.33.7 with a change to GNUmakefile that removed the need for a somewhat cumbersome configuration argument.
With the release of perl-5.22.0, the NV type of long double was enabled on Windows, and now we finally get the additional option of having the __float128 NV type.
All of this does, of course, rely on using mingw-w64 ports of gcc to build your Windows perl.

I think that many of us, accustomed to simply using Strawberry Perl, don't realize just how easy it is to build perl from source on Windows.
Strawberry Perl, itself, does provide us with the toolchain that's capable of building any recent version of perl (including blead releases) from source.
The latest blead source can be obtained with:

$ git clone https://github.com/sisyphus/perl5.git blead_clone
[download]

or the perl-5.33.7 development tarball is available from:

https://cpan.metacpan.org/authors/id/R/RE/RENEEB/perl-5.33.7.tar.gz
[download]

Then, I place my C:\_64\strawberry-5.32.0\c\bin folder at the beginning of my PATH, and I have all that I need to build perl.
Simply cd to the perl source's win32 folder and run:

gmake INST_TOP=C:\bleadstraw CCHOME=C:\_64\strawberry-5.32.0\c CCTYPE=
+GCC I_QUADMATH=define USE_QUADMATH=define test
[download]

Then, to install perl into the location specified by INST_TOP, just run:

gmake INST_TOP=C:\bleadstraw CCHOME=C:\_64\strawberry-5.32.0\c CCTYPE=
+GCC I_QUADMATH=define USE_QUADMATH=define install
[download]

And that's it - in C:\bleadstraw I now have a Windows perl that has __float128 as its NV.

You may want to alter INST_TOP, and you probably need to alter CCHOME which should specify the full path to gcc's bin directory.
NOTE that CCHOME does not include "\bin". (Failure to get CCHOME right will cause some test failures, but will not affect the perl that has been built.)

If you want to do a 'long double' build instead, you would just remove the 2 gmake arguments that include the string "QUADMATH", and insert the USE_LONG_DOUBLE=define argument.
If you don't request either a 'long double' or a 'quadmath' build, then the nvtype will be 'double'.

If you're using a 32-bit compiler, you'll also need to insert the argument WIN64=undef, and you might also want to add the argument USE_64_BIT_INT=define if you want 64-bit integers and pointers.
With 64-bit compilers, perl's integer and pointer will inevitably be 64-bit.

I think that covers the most commonly exercised options ... but you'll find additional options laid out in the GNUmakefile.

I don't know if it's a general issue, but (on 64-bit builds only) there's usually a couple of test scripts in cpan/IO-Compress/t that hang for me .
Update: This issue is a long-standing one for me, and is not limited to just the "quadmath" builds.
It's generally (but not always) the same test scripts that hang, and it has been happening for a few years. In perl-5.33.7, I'm finding that the problem has moved to a different couple of files.
The Strawberry project have never, to my knowledge, complained about such an issue - so I'm hoping that it's just something in my particular environment.
It would be nice to find out if it is "just me".
It's quite annoying - I have to kill these hangs using process explorer in order to get the test suite to run to completion. (Killing them with Ctrl-C kills the entire 'gmake test' process.)
These test scripts have always passed when run outside of the testing harness, and they've also passed even when I've run make test in the cpan/IO-Compress folder.
There's also the same thing happening in the cpan/IPC-Cmd tests with t/01_IPC-Cmd.t.
If I can find any evidence that it's also an issue for others then I'll try to get it fixed.

Oh, one last thing - if you build a 32-bit perl with I_QUADMATH=define USE_QUADMATH=define but without USE_64_BIT_INT=define, then expect some failing tests in Math::BigFloat due to a Math::BigInt::Calc bug.
This issue has been reported, with a proposed simple fix to Calc.pm.

Cheers,
Rob