I don't really care about Windows ARM, the bigger question is, will we get a way to also run x86 machines.
Well, Apple Silicon will never be able to run x86 natively, so whatever solution you choose, it will involve emulation or translation. Bottom line is that if you
really need native x86 and old-school Windows, you need an x86 machine.
Windows for ARM has x86 emulation, and it is getting better (64 bit support has just launched) and is always likely to be more efficient than emulating the
entire OS.
Failing that, it looks like you'll probably have QEMU/UTM for x86 emulation, at least.
* Apple will keep selling Intel systems for a while longer; I'm sure however this will stop at some point
Well you have a couple of years before you are forced to change, and a lot of water will pass under the bridge before then.
The M1 is a potential industry changer, and although it probably won't end with Apple ruling the world, it is a huge credibility boost for non-Intel processors and code translation that could help Windows-on-ARM become more mainstream. The idea of having a RISC-like processor that relies on software to translate legacy x86 code is not new - both the Intel Itanium and Transmeta Crusoe tried that and failed years ago - M1 and Rosetta have shown that it can work well. Then, "modern" Windows apps - and many Android apps - compile to bytecode rather than x86 binaries (afaik not quite transparently portable yet, but well on the way). Not to mention the increasing importance of "web apps" which are generally processor independent.
* Run your systems in the cloud or via an on-premise virtualization environment; which is a valid option, but cloud is already out due to security restrictions
I think a lot of people will find that one flipped on it's head in the near future: you'll
have to use the cloud or VPN into your workplace network
because of "security restrictions" (or to be more accurate, due process, accountability and record keeping for backside-covering purposes when the inevitable breach happens). The current pressure for remote working will help there. Seriously, which is less secure? (a) Local copies of data scattered over multiple users' desktop PCs and laptops that can be left on trains, reliant on each individual user's security practices - or (b) a cloud server protected by strong encryption, every connection monitored, no databases leaving the system, managed backup, archiving and deletion services, any user can be instantly blocked if a breach is suspected... and, better still, outsourced to a specialist provider who you can
sue if there is a breach at their end...
Yes, performance might suck, but hey, the new M1 socs are super powerful and outperform Intel chips, right...?
What is in Apple's best interest? Make the best MacOS machine possible - or compromise on that so that the Mac can also be a rather expensive 90% compatible Windows PC? While Intel were making the best chips (and IBM/Motorola weren't delivering the PPC chips Apple needed), they could easily do both - indeed they could hardly
stop it: I don't recall Apple ever promising the ability to run Windows until a bunch of hackers worked out how to do it, and Parallels/VMWare were third-party developments.
Now Intel aren't delivering the chips that Apple need, and Apple are in a position to reap the benefits of making the best processor (for Macs) themselves. Some eggs will get broken to make that omelette.
Windows-on-ARM virtualisation looks like it is going to happen unless MS blocks it, and between that, QEMU and (likely) remote Windows-on-cloud services will meet the needs of a lot of people who are obliged to use some Windows software for work. I suspect that will be enough for Apple, for whom encouraging Mac users to run Windows is, to say the least, a two-edged sword.
(...and ARM Linux has its own momentum irrespective of Apple Silicon, and is already far better developed than Windows-on-ARM - the Mac could find a new niche in a world where there are plenty of ARM-based servers but no nice ARM laptops for developers, although I suspect that will become less and less CPU-dependent as well).
