Older development of NUT for Windows was modernized over past months, and now merged as part of main codebase (post-v2.8.0). Caveat emptor!
Better read up in comments to #5 and #1611 and #1050 to an extent. The short of it is that syntactically NUT builds pass without warnings, and survive integration tests (upsd and some dummy-ups setups).
Doable in linux+mingw (using an older build script to arrange configure options) and in Windows+MSYS2 with plain configure or same ci_build.sh as CI builds on other platforms use to arrange it. Prerequisites are listed in scripts/Windows/README and docs/config-prereqs.txt respectively (or now also actionably wrapped by appveyor.yml). Known caveats are in NUT for Windows project as open tickets in https://github.com/orgs/networkupstools/projects/2/views/1 project.
In particular, "purely native" builds (e.g. with Visual Studio) were not attempted yet, not that I know of. The goal was to have something usable first, so first winners were even two - GCC builds with mingw (on linux and in MSYS2), with ccache recommended for faster iterations, with x86_64 and i686 targets. Probably clang is doable, but was not tried yet. Passing in custom CFLAGS into MSYS2 builds (as pre-set envvars or configure argument) caused issues for that build of gcc itself (somehow became part of path it is trying to build in). There are more variants of standard library to juggle too (UCRT etc.) for portability across Windows releases vs. modernity.
Due to availability/easy-buildability of third-party dependencies, these build scenarios currently have some non-overlapping results (notably libgd/cgi, snmp and neon/xml are known inconsistencies).
USB HID may need more work, possibly installing a low-level driver in OS, to see devices in detail. Maybe that was solved by predecessors in MSI packaging, not re-investigated yet with recent effort.
Parts of serial driver codebases are ifdef-ed away.