In a lot of ways, having this be based on k8s provides a lot of flexibility and independence, and with k8s there's much less friction to providing computes with high locality relative to applications/users application code.
It's also the case that by staying with k8s we can take advantage of existing operational tooling, experience, and work, and can focus or development time on the important parts of this problem: runtime scaling, scheduling, and virtual machine management and not on cloud provider APIs and management.
In short, k8s gives us options that we like for the future, it's shortening the development cycle, and only getting in our way a below-average amount. At the same time--for the most part--we're building this with reasonable abstractions that would let us reuse our existing work if k8s becomes more trouble than it's worth.
Sorry, these release notes reflect the 2.2-rc0 release candidate and do not reflect the release of 2.2, which is still forthcoming. rc0 is currently available for testing.
Truthfully, I don't know that it's going to kill conventional editor or editing habits (and by the time it does, I suspect that web-based IDEs will look significantly less like today's web-apps than they do today) and more that this technology will find a niche in code review, or version control interfaces, or something like that, but it's a nifty idea.
I think the definition of "mainstream" audience, in the first paragraph is the beginning of the problem.
If we continually redefine the "mainstream" audience to lower and lower common denominators, as the people who don't know and care about the technology they use, why should they ever care to use linux?
One of the biggest powers of free software is it's ability to teach people about computers and how technology works, lets start from there.
Well, I think we're using the term design in a couple of senses. The sites you provide (and dozens of others, really there are a lot of awesome sites running on Drupal) are solid, clear, high quality websites. They have good visual designs and layouts, and they have managed to scale well. This is true.
They aren't groundbreaking websites, however. They do their job well and all of those sites are successful because their owners/content was successful before their current drupal incarnations were developed. I'm also aware that there are some sites that have launched their 1.0's as drupal sites, I think it's pretty safe to say that these sites are familiar conceptually (like digg, like slashdot, like etc.) In that sense they don't have "amazing" designs.
Perhaps we should rephrase this as "you will never create an innovative desgin in Drupal." I'm generally in favor of Drupal, but I think this is probably the truth.
It's also not a bad thing. Websites need to excel at presenting information above all else, and drupal sites provide a lot of power to make this happen. Most websites are adjuncts to other things that organizations and individuals are doing, and they don't need to "shift the paradigm of web design and architecture." Lots of people need websites like this, and drupal's ideal for these cases.
---
I think the "you'll never create a successful startup in Drupal," statement requires a bit of a clarification, but it's probably mostly true: given the constraints and assumptions of the platform, you're unlikely to create a new kind of website in Drupal that will succeed on the Internet. The next boom of new websites (like blogs in 2000, or social networking sites in 2004, or webapps in 2008) isn't going to be built in in Drupal first.
But it will be built in drupal second (maybe,) Drupal is great for making custom instances of websites that are targeted at niche/specific audiences. And that's a huge chunk of websites. It doesn't make a lot of sense to build highly local sites like "digg-chicago" and "digg-Sao.Paulo" all in custom-built perl or ruby based sites, when something like Drupal promises to make development and maintenance much more simple in the long run. These kinds of sites have a great deal of worth and potential.
---
As for lean and scalable.
Totally the truth. Drupal can scale, but it's a pain in the ass. Which means, a sliver of the huge gains made in development times and maintenance times is absorbed by increased architecting costs. Lots of memcache and hardware can fix this problem. But if you get to the point where you get to that level of demand, presumably you'd have to have a sysadmin on staff anyway, so I'll concede the point, but I think it may really be a draw.