I actually had very high hopes for the Surface laptops, almost bought one, but didn't have an excuse large enough to justify the cost. (I already have lots of computers, too many, some would say...)
I've always been willing to cut Microsoft slack for the fact that their software runs on other people's hardware, and is operated mostly by people who don't understand it. As you say, that's not the case for this article.
I'm willing to cut them about as much slack on their own hardware as I'm willing to cut Apple on their hardware. That is, mistakes happen, bugs slip through QA, sh*t happens. The idea is to rapidly acknowledge and fix it.
With regard to running Windows in a VM on (say) Apple or other hardware/OS combinations, I've overall had FAR fewer problems in that mode, compared to Windows on any metal. And yet you would think that inserting an additional, complicated variable (VMware, VirtualBox, etc.) ought to INCREASE the problems. But surprise, Windows runs just fine as a VM. Go figure.
If you think about the hardware set a VM uses, it then makes sense. It is either a synthetic device or an emulated one. Emulated devices use the host’s kernel, and synthetic drivers go through/use a hypervisor that is under the kernel and therefore doesn’t need to wait for kernel mode interrupts. But in either case, there is only one video driver, one sound driver, one keyboard/mouse driver, etc., etc.
I think this points to the hardest thing the software has to do is perfectly map hardware’s primitives, I.e., machine code instructions, when there is so much disparate hardware out there. And then add to that that different assemblages of hardware can further muddle up driver code that would be fine by itself.
Aside from operator error, this is the hardest thing to test for. Who knew that one guy would still be using that piece of crap, cheap Chinese scanner and how it’s driver had to fake out some interrupt needed by every component ?