For one example, Windows ARM kernels are pretty tied to the GIC (ARM's reference interrupt controller), but Apple has its own interrupt controller. Normally on ntoskrnl this distinction would simply need hal.dll swapped out, but I've heard from those who've looked into it that the clean separation has broken down a bit and you'd have to binary patch a windows kernel now if you don't have source access.
What you can do is having a small hypervisor to simulate the needed bits…
"Apple designed their own interrupt controller, the Apple Interrupt Controller (AIC), not compatible with either of the major ARM GIC standards. And not only that: the timer interrupts - normally connected to a regular per-CPU interrupt on ARM - are instead routed to the FIQ, an abstruse architectural feature, seen more frequently in the old 32-bit ARM days. Naturally, Linux kernel did not support delivering any interrupts via the FIQ path, so we had to add that."
https://news.ycombinator.com/item?id=25862077
TL;DR: No standard ARM interrupt controller, custom controller requires quirky architectural features
My next point was about how the NT kernel was designed to handle exactly this kind of change pretty cleanly, but that clean barrier has been allowed to stagnate. So way back, NT kernels for weird systems like SGI workstations that had x86 CPUs but were decidedly not PCs otherwise simply needed hal.dll swapped out with a version written by the hardware vendor to paper over those system differences like how interrupts are routed around and how to access PCI devices. That's no longer really an option however.
Windows has some behavior that is hard-coded and cannot be changed except by Microsoft. This behavior can fairly easily be bent on Linux, but Windows drivers can't bend the rules for some of these issues.
The biggest issue that immediately comes to mind is that the M1 MMU (Memory Management Unit) only can handle 16K pages. Linux can easily be built for 16K, and most programs work on 16K, but Windows currently only supports 4K on ARM. No driver can fix that - only Microsoft. Of course, if Microsoft joins the Apple Silicon train (which Apple has said they are more than welcome to do), then they probably will have official Apple documentation and not need the Asahi Linux findings.