The real problem with the Apple chips is that they do not do virtualization. On my Studio, I had hoped to be able to run Parallels with Windows subsystem for android, but that is impossible.
They don't do virtualization? Then how is your Parallel App running on top of Apple's Hypervisor framework? M-series does support virtualization.
"...
The Hypervisor framework has the following requirements:
Supported hardware
The Hypervisor framework requires hardware support to virtualize hardware resources. On Apple silicon, that includes the Virtualization Extensions. On Intel-based Mac computers, the framework supports machines with an Intel VT-x feature set that includes Extended Page Tables (EPT) and Unrestricted Mode.
..."
Build virtualization solutions on top of a lightweight hypervisor, without third-party kernel extensions.
developer.apple.com
All the virtual machine software on Apple silicon run on top of the Apple's hypervisor framework. The different virtual machine vendors can add 'features' on top but the foundation is commonly shared. (for better or worse. Contributes to why VMWare is lagging because because they have to loose their own lower level but try to look like they didn't (so seamless with rest of VMWare VM empire. The other empire is their primary business. )
"...
The Virtualization framework provides high-level APIs for creating and managing virtual machines (VM) on Apple silicon and Intel-based Mac computers. Use this framework to boot and run macOS or Linux-based operating systems in custom environments that you define.
..."
Create virtual machines and run macOS and Linux-based operating systems.
developer.apple.com
Apple does some basic stuff for macOS and Linux layered on top of the hypervisor. Minimally completing with the VM vendors. Apple isn't chasing Windows here though.
Android on Windows on MacOS needs
nested virtualization; not just plain virtualization. This hasn't been a high top priority for Arm more than several years back.
"...
Before the release of Armv8.3-A, it was possible to run a Guest Hypervisor in a VM by running the Guest Hypervisor in EL0. However, this required a significant amount of software emulation, and was both complicated to implement and resulted in poor performance. With the features added in Armv8.3-A, it is possible to run the Guest Hypervisor in EL1. With the features added in Armv8.4-A, this process is even more efficient, although it still involves extra intelligence in the Host Hypervisor.
..."
developer.arm.com
Arm v9 this is more commonly 'baked in'. It didn't make much sense for Apple to do nested virtualization before Arm had worked out the kinks on what would be the standard way to do this. The issue is more so where does Apple 'merge in' with the Arm standard approach with the specifics of Apple's security model and their implementation. It would help Apple long term if they did something that didn't hugely deviate from the standard Arm approach.
It wouldn't be surprising if Qualcomm ( what Windows on Arm is generally built toward) isn't on the bleeding forward edge here either. Ampere Computing (and other Arm Neoverse implementers probably are).
It is much better risk management for Apple to get a solid "one level" virtualization done before moving on to multilevel. However, if going to pragmatically ban everyone else's hypervisor at some they do need to add another level to a rock solid foundation.