As an Android user, given my (now) better understanding of the Android architecture design, I am happy and safely say that Android was made for the future, and is only gonna get better from here on.
The reason that the keyboard is required to be implemented "from the system up" is that Apple idea of an "App Store" is fundamentally opposed to the idea, not because of any technological restriction. Apple only sells "apps" with "icons" (by choice), but this gives them one fundamental advantage: all apps are identical, and completely self-contained. I don't agree with that — I use a jailbroken iPhone, for one. But I definitely do see the value for users who don't know what the idea of "an alternate keyboard" would even mean.
(On a jailbroken iPhone, I could likely move the keyboard out of process with a week of work; Apple could surely do it even faster. They just don't have any need to: there is no possible situation where, to them, the "flexibility" of alternate input methods is superior to the mental simplicity of just selling an "app" with an "icon".)
iOS applications also run in separate processes and are just as secure as Android apps. There's nothing "made for the future" in the poor up front design choices the Android team made early on.
In fact, we can clearly see that the iOS team made all the right decisions because drawing/compositing in iOS on a 3GS is faster and smoother than on a shiny new Android Inspiration XL HD 4G.
Also, Dianne shows a fundamental misunderstanding of how drawing/compositing works on iOS. So this entire series of posts is just moot. The other guy (Windows Phone guy) had no idea how Android or iOS worked, either.
The most annoying thing about all this is that none of these views are based on actual facts -- and we all know what happens when someone is wrong on the Internet.
At the end of the day, who cares which one is better or how it's implemented? I don't care about the "Android has windows" explanation because it's irrelevant to me as an end user. It's all about perception.
This entire Android vs iOS thing is getting long in the tooth.
Edit: also, it's going to take a long, long time to be able to pull off something as awesome as Core Animation. Or Core Text. Or Core Graphics. These things have been stewing in OS X for more than a decade.
The same goes for Core Text or Core Animation - they are not doing anything especially hard or mind blowing. Android displays text just as well and has an animation APIs that are arguably easier to use that Objective C APIs.
Its frustrating and annoying to read posts like this where you try to walk a "I'm impartial" line and then pepper it with biased remarks that are misleading. You are unlikely to get more factual discussion about the situation then the post she offered, as she's a creditable expert who has written a not insignificant portion of the OS under discussion.
Its clear that iOS has some really technical achievement they should be proud of, but your desire for facts about the situation is subverted by your very own use of statements like "drawing/compositing in iOS on a 3GS is faster and smoother than on a shiny new Android Inspiration XL HD 4G" without anything to support your position. Its not a fact because you make a statement.
Seriously: you should trust Xuzz from this thread much more than Dianne about issues related to iOS surface compositing. Xuzz worked on jailbreakme with comex, did much of the work for the recent Siri-on-non-iPhone-4S ports, and has written numerous modifications to the code of SpringBoard (the main window manager and graphical shell process on iOS) over the last few years he has spent reverse engineering that system, and most of his posts on this thread are corrections to statements that Dianne seems to have simply made up for this article of hers.
(For "people to watch" on this thread, I should also point out ryanpetrich, who is responsible for such modifications as DisplayRecorder (which records the iOS framebuffer to a video file) and DisplayOut (which splits the framebuffer out to a television), both available for jailbroken devices.)
Your assumptions are based on the fact that no official APIs are provided to modify the OS in a sweeping way. Apple could very easily implement such a thing if they wanted - they would simply have to shift some code around. The reason Apple does not do this is because Apple favors simplicity over flexibility, or rather, maintains a balance between the two.
Google wanted Android to be ubiquitous and free to quickly evolve into whatever it needed to be to be in order to capture territory in the mobile device world. That means supporting a wide range of devices, technologies and, most importantly, partners (both hardware, software, carriers, etc.). So Android was designed for flexibility and has extension points everywhere (input frameworks, sharing, alternative browsers, launchers and so on). Google gave up performance along many dimensions in order to maximize Android's adaptability.
Apple is very different. They have a vision and want to build that vision as precisely as they can because that is what has driven their success. That means Apple doesn't want hardware partners. And even at the software level, thsat means they are very careful about who and what they allow into their user experience.
You can see this in how they built new features for iOS 5: Apple added a split keyboard for the iPad rather than adding support for alternative keyboards. They bought Siri rather than exposing relevant extension points. Apple baked Twitter into iOS 5 as a one-off, rather than riffing off of Android's sharing (as they did with notifications). And so on. These are all business decisions, not technical ones (as Cydia often proves). Instead, iOS's technical architecture flows from Apple's goals in the same way Android's flows from Google's.
For example many people claimed early on that iOS 'didn't support multitasking', which was correct at a feature level, but not at an engineering level.