Nothing is stopping a community for creating an RFC to compete with a proprietary API and if you push it through and are successful and create an ecosystem, then Facebook might implement it on top of their proprietary API.
Several groups have tried and failed. The main problem is that Facebook owns the ecosystem today, and it's incredibly difficult to compete with that. Facebook has no incentive to inter-operate with anyone else, and they shut down any third-party integrator that they deem to be a competitor.
I was once optimistic that "the rest of the web" could band together and create a decentralized system more interesting than Facebook, but Facebook has done such a good job of creating a hub-and-spoke model where Facebook is the hub and everyone else is the spoke that it's really hard to pivot from there to a truly-decentralized social network.
A large reason for that is that watching shows on broadcast TV is pretty damned inconvenient.
I discover every day new shows on Netflix that aired years ago but I wasn't able to watch either because I wasn't in the right country (wasn't in the US) or because I had something better to do when they aired.
However, if these things had been available for on-demand streaming from the outset I'm quite likely to have watched them, just as I currently watch new TV shows on-demand through Amazon VOD or Hulu.
You made an error in your third line:
.5 * 10 = 5
4.5 / 9 = 0.5
0.5 = 0.5. QED.
The original nook gets "free" 3G because the device (as shipped) is locked down so the only thing you can do with that 3G is buy books from Barnes and Noble and download them. The cost is eaten by B&N as part of the book purchase costs. Note that in particular the included web browser application only works when a wifi network is available.
Nook color is unlikely to get this functionality unless they can find a way to allow third-party apps on the phone without allowing them to use the subsidized 3G.
Given that "wine is not an emulator" but rather a library that mimics the Windows API and a loader that understands the Windows executable format, the code that is running is native code for your architecture and can potentially do anything a native application can assuming it's been written with that in mind. So you should expect a Windows application running under Wine to be able to do anything a native application could do running under the same user account.
There is one aspect of running under Wine that leaves you in a better situation than running on Windows XP: on Wine, the entire Windows filesystem lives under your home directory as far as the native OS is concerned, so you never end up running things as Administrator (or root) to get them to run, which means if someone does make a rogue Windows app that detects when it's running under Wine and tries to do something mean it'll be constrained by the access rights of your user account in all cases.
I think the crux of the issue here is that Apple is the party distributing the app via its app store, and as a distributor it is bound by the licence of the software. In this case the licence is the GPL which requires that all binary distributions be accompanied either with source code or an offer of source code. Therefore to be in compliance Apple must at the very least make available the source code of the application by some means. Other requirements in the GPL may apply here too.
Engineering of application-layer protocols is far easier when everyone is addressable. The deployment of NAT has had a cascading effect on many application layer protocols that would have had a simple, obvious implementation were every node equally addressable. Instead, every new application protocol has to consider and work around NAT.
So sure, as we stand today that ship has sailed and NAT has created a hierarchy of nodes that is unavoidable in today's network engineering, but I wonder how much innovation has been stifled by time spent working around NAT.
What is worth doing is worth the trouble of asking somebody to do.