The issue is not the (inconvenient, but mostly a problem for developers who are paid for that stuff) fact that you can't easily write one piece of software that suits two or more processor architectures and UI paradigms, at least not well; but the fact that the various emerging platforms are locked down hard.

Yup, just dumping your desktop application onto a phone isn't going to work out too well, even if it is architecturally possible. Fair and natural enough. The problem is that all the various up-and-coming devices(with unpleasantly limited exceptions) are shipping deliberately crippled. Purely for architectural reasons, nothing on OSX would run on iOS without a recompile, and very little would be pleasant to use without a UI redesign; but that is largely irrelevant because you need a cryptographic blessing to even execute. Windows-on-ARM appears to be going the same way, and, while Android lacks such a centralized dictate, your average carrier phone has a few locks in place.

Portability is an engineering and UI/UX hassle. The fact that you can't even try to execute a binary without the blessing of the platform's master is Serious.

There is another possibility: Microsoft has massive legacy commitments. Practically all the world's boring corporate stuff that isn't old, specialized, or hip, enough to be running on some sort of intimidating big iron or linux/web/cloud/thingamawhatsit. Most of that software is absolute dreck, and rather boring, but much of it is also quite critical to a variety of high value operations and impossible or uneconomic to port or even modify very much. For this reason, Microsoft's walled-garden options on x86/64 are pretty minimal. Architecturally they could roll it out tomorrow(Software Restriction Policies are basically that, but under the control of your domain admin); but the customers that matter would scream like nobody's business.

However, since there isn't any legacy Windows software or legacy Windows device drivers, on ARM, since it has never run on ARM before, there is no legacy market to worry about. Microsoft has a free hand, more or less. As with the xbox, the other recent situation where MS started clean, without legacy impediments, they apparently see a walled garden as their best option.

It remains to be seen how long the momentum of more-or-less-open x86 IBM compatibles will carry them into the future; but so long as the legacy/in-house/custom demand is there, they'll be hard to kill entirely. However, I'd say that it is "outlook not so good" for open platforms any time somebody starts a new one from scratch...

It was produced by an ex-Apple employee's startup, after all...

As it happens, not only can you, a great many of the patent law systems of the world do to some degree or another(it seems to be even more common with copyrights; but also happens with patents). All Paris Convention for the Protection of Industrial Property signatories(1883-Present) possesses the right to create compulsory licenses under certain circumstances.

In the specifically US context, it's worth noting that patents and copyrights are listed as something Congress may create(but is not in any way obligated to) and specifies only that these be of limited duration. They aren't treated at all as though they belong in the 'natural rights' set.

As a matter of fact, I find it rather unlikely that Nest has a chance of getting a compulsory license; but that's just a matter of particular law, not some sort of foundational principle of jurisprudence: the only place you'd really see it articulated would be by somebody who has been inculcated with both historical natural-law justification of property and quite contemporary 'intellectual property' maximalism. Not a forbidden position; but actually quite an atypical one...

I'm assuming that the Nest and some Institutional/industrial networked HVAC controller made by Honeywell(probably one where 'web based' still means "serves a java applet that requires a JVM five years old to run, after authentication in plaintext with a password of no more than six characters, for an extra license fee we'll turn on the SNMPv1 interface..." both implement some concepts that would be familiar to anybody who has perused a control theory textbook and/or some things that programmers building network applications have forgotten that they remember...

I'm guessing that this isn't exactly a 'look and feel' lawsuit(though the iconic round, bimetallic spring, mercury tilt switch design was Honeywell, that's sort of their last brush with being on the leading edge of intuitive thermostat interfaces...)

Don't you remember that everything one can do with a computer is magically novel and patent worthy each time you change the context even slightly?

It was patent-worthy when "on a mainframe" was appended(though much of that has expired by now, so it isn't a matter of significant practical concern)
It was again patent-worthy when done on a PC.
You'd better fucking believe that doing it "on the internet" made it patent-worthy all over again and then some.
On a 'smartphone'. Oh you know it, and twice as shiny...

Given the painful uselessness of CRLs as presently implemented(we obviously need some way of revoking the things; but the present one is agonizingly broken), I'm just not too sad about the prospect of no longer telling Verisign every time I visit one of their SSL-cert customers(the same is true of all the other certificate mongers who publish CRLs)...

According to the present wiki information Model A received "Onboard Network: None".

Neither model precludes a USB wifi dongle(and some stuff, particularly some RaLink, actually works); but it looks like the default options are either "None" or "10/100 ethernet provided by a SMSC9512 USB hub/Ethernet controller hanging off the SoC's USB master port.

A case design allowing for a USB dongle to be installed; but protected inside the case, should be trivial enough; but is not default.

Compared to iOS, OS X is a hippie commune all smoking freedom joints in a big freedom love-in; but it has its quirks...

If Nvidia is working on it, it seems quite likely that ARM, as in the instruction set, won't; but ARM, in the same sense that "x86" can also describe a computer built around a specific CPU, quite possibly will.

Given Nvidia's (comparatively mature) GPU compute ambitions, and their displeasure at the fact that Intel has been shoving them out of all but the fat-'n-bulky laptop designs and discrete GPU desktop/workstation designs, it seems very likely indeed that Nvidia wants two things from ARM:

1. An ARM fast enough to, when combined with an Nvidia GPU, produce a tablet/laptop that people won't laugh at in comparison to a ULV i3/5/7 + Intel GMA.

2. An ARM fast enough(and with enough PCIe lanes and memory controller ability) to do boot, housekeeping, and care and feeding, for a big stack of 'Tesla' compute silicon.

Neither really requires(nor would it be obviously sensible) ARM to go up against high-wattage and relatively low thread-count x86 parts(in which struggle Intel is a very, very, dangerous adversary, and AMD a dogged and inexpensive one); but they likely would want something that can provide an adequate user experience compared to the intel power-constrained stuff, and something that can allow them to sell all-Nvidia Tesla compute stacks.