It's also important to remember that Microsoft was in the middle of their Qualcomm exclusivity deal at the time of the M1's release, and thus Windows for ARM wasn't available on anything other than a few select devices or unofficial use of Insider builds.
That deal didn't actually expire until 2024[1], at which point Windows for ARM finally started to be sold in an official capacity with stable builds widely available.
It's entirely possible, though unconfirmed, that Apple was intentionally leaving the door open for "Boot Camp 2", and Microsoft simply never took them up on the offer, either because they were stuck in a deal made prior to the M1's release that prevented it, or because they no longer saw a financial benefit to being able to sell Windows to Mac users (possibly since Windows license sales are effectively a rounding error to Microsoft at this point; they make way more off of subscription services and/or Office, all of which are already available on macOS without having to dual-boot Windows).
[1]: https://www.tomshardware.com/pc-components/cpus/windows-on-a...
AFAICT, the way Microsoft wants things to work, is that "Windows" is the native fat-client platform / SDK that ISVs are supposed to use/target when building fat-client apps that interact with (i.e. generate spend on) Azure-based backend systems. The #1 way Microsoft makes money at this point isn't from direct consumer or even volume-licensed subscriptions; it's from providing paid backend infra to dev shops who had long since locked themselves into the Microsoft/Windows development ecosystem, and who therefore saw Azure as the only valid cloud backend to integrate with when "cloud-enabling" their software (and/or, where the compliance story of integrating their previously native-and-local-syncing software with Azure, was 100x simpler than with integrating with any other cloud, due to Azure+Windows being able to act as a trusted principal-agent pair that can enforce policy-based security via a shared "cloud domain" identity [Entra ID] baked right into the OS ACL layer.)
Until recently, though, Microsoft thought of the Windows "platform" the same way Apple do of the Mac "platform": that "Windows"-the-platform-SDK was the same thing as Windows-the-OS. Which necessarily meant that consumers must be pushed with all conceivable effort toward using Windows-the-OS on their machines, so that these dev shops who had targeted Windows-the-SDK could reach them with their software (so that those dev shops would in turn spend more on Azure.)
But I think this equivalence is going away!
From what I've seen of discussions in various Microsoft-aligned sources recently, it feels to me like some part of what Windows 12 may mean by calling itself a "modular OS", is that Microsoft may be establishing some kind of very clean boundary layer between Windows-the-OS and Windows-the-platform/SDK.
---
What would that look like? I don't know for sure, but here's some spitballing:
Picture Mono, but as a complete UWP projection, shipping with all the native libraries that are built into Windows.
Or, if you'd prefer, picture Wine/Proton; but rather than black-box-reverse-engineered equivalents to Windows DLLs, it is all the DLLs that come with Windows. Except, now rebuilt from the ground up so that they compile against NTOS or Mach or Linux syscalls.
Basically, "the complete Windows platform" as a JVM-like runtime you "get for free" when installing Windows-the-OS, but can install on top of macOS and Linux. (Probably in various runtime profiles, as with Embedded vs Server vs Desktop JREs. You don't need D3D on your server.)
This would be likely to take 100% of the wind out of the sails of the Wine/Proton projects overnight. And maybe kill Mono itself, too. After all, why bother with half-assed third-party implementations of the Windows Platform, when you can just install the "real" Windows Platform, and get guaranteed bug-for-bug compatibility with existing Windows software (relying on the same databases of app shims and fixes Windows-the-OS has shipped with for ~forever)?
SteamOS would be reduced to "a Linux distro that preinstalls the Windows Platform." ReactOS might or might not (depends on stubbornness) be reduced to "a clean-room-implemented NTOSKRNL-compatible base OS, that preinstalls the Windows target of the Windows Platform."
Wine/Proton themselves would, if they even bothered to keep going, end up rebranded as "an alternative ground-up Windows Platform runtime." (If the official "Windows Platform runtime" was then open-sourced, then likely Wine/Proton would fully fade into obscurity, as anyone who wanted to maintain their own libre Windows Platform runtime would just start by forking Microsoft's. Very similar to the situation with OpenJDK.)
---
In any case, regardless of how they do it, any move in this direction would make it blindingly obvious why Microsoft wouldn't care about enabling something like a "Boot Camp 2" feature on Macs any more: they no longer care if you install Windows-the-OS on a Mac; they rather want you to install the Windows Platform runtime under macOS. And then they'll have you as a consumer of Windows Platform products all the same.
(Actually, even better, as they'll have you far more of the time. In the Boot Camp business strategy, any time you spend booted into macOS puts you out of Microsoft's reach, save for the few first-party apps Microsoft has ported to macOS + sells on the App Store. In the Windows Platform business strategy, meanwhile, you can be running arbitrary Windows Platform apps on your Mac [and so generating Azure spend for some ISV somewhere] 100% of the time you're using it!)