NUT v2.8.1 release: TLDR version
Generally you can preview the live list of notable changes since 2.8.0 release at https://networkupstools.org/historic/v2.8.1/docs/release-notes.chunked/NUT_Release_Notes.html#_release_notes_for_nut_2_8_1_what_8217_s_new_since_2_8_0 and for things that are expected to impact packaging and upgrades (whether by some possibly breaking disruption, or by adding new ways to automate things more efficiently that the audience could benefit from) - at https://networkupstools.org/historic/v2.8.1/docs/release-notes.chunked/NUT_Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1 - with such release notes publication also being a recent addition.
NUT for Windows is back!
Older development of NUT for Windows was modernized over the past 15 months or so, and was merged as part of main codebase (in 2022, post-v2.8.0). Still, 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 data server and some dummy-ups driver setups). The binaries can be executed on the platform, drivers can see physical UPS devices and upsd represents them on the network; deeper integration was not tested much yet.
Builds are 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). Parts of serial driver codebases are ifdef-ed away.
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. See one practical success story at #1690 (comment)
Maybe that was solved by predecessors in MSI packaging, not re-investigated yet with recent effort. The need for that research is tracked as #1485
These and other known caveats can be seen in NUT for Windows project as open tickets in https://github.com/orgs/networkupstools/projects/2/views/1 project.
Happy Halloween!