> Так файлов может и не быть. Данные не обязательно должны быть агрегированы
> в файлы.
> Например одна большая база данных, или состояние процесса

1) Во первых, это тоже нестандартный костыль.
2) Во вторых, вот вы и пользуйтесь этим недоразумением наздоровье. А мне это и бесплатно не надо, потому что я тогда не смогу получить письмо с аттачем, сохранить аттач на диск телефона как файл а потом прицепить сие к компу по юсб и просто файлманагером скопировать файл туда. Ваши недоноски как-то не способствуют "mission accomplished". Поэтому убейтесь веником: мне не надо недоносков. Жуйте такое сами.

>> сделали на куте более-менее культурно и ... начать с нуля на
> Вместо стандартного может появиться универсальное. Так же как в Unix, везде стараются
> использовать файловый интерфейс.

Скорее всего появится еще один велосипед с турбонаддувом не оформленный как часть стандарта. Потому что пока в стандарт все протолкаешь - времени уйдет дофига, а бабло рубить охота уже сейчас.

>> 3) Там нет стандартного апи для работы с сетью и понимания текущего
>> состояния оной. См пункт 2)
> Так и сети может тоже не быть.

А может - быть. И как бы хорошо если аська видит - "ага, сети нет, долбиться не будем - будем раз в минуту проверять не появилась ли она". Или, "мы приконектились к сети "home" и поэтому идем онлайн, поскольку это наша сеть".

> Просто есть рабочее пространство, а откуда там, что берется это уже не
> дело прикладного софта.

На это нет _стандартов_ а велосипедов и в андроиде хватает. Нафиг сдался HTML5 который ни с кем остальным не совместим? И чем это будет отличаться от ни с чем не совместимой Java которая не совсем Java в андроиде? Такие приложения же не будут работать на допустим обычных компьютерах, так ведь? :)

>  Например, телефонные линии раньше были пионерские, ведомственные, городские, междугородние, международные
> ... межгалактические ;). И при работе с каждой были свои правила
> (API). А сейчас от пионеров до почти космонавтов болтают по интернету.

Опять же - вопрос стандартизации API. В андроиде вон положили на это. И эти наверное то же самое сделают...

> Скорости линий и вычислений растут. Вполне можно вернуться к истокам: небольшие библиотеки
> + скрипы для клея.

На телефоне как бы еще есть проблемы с батарейкой. И чем быстрее молотит проц на повышенной частоте, тем быстрее от батарейки ничего не остается. А таскать чемодан аккумуляторов ради удобного клея - да ну вас таких нафиг!

> Тот же LibreOfficeб с нативным гуем, на старте тормозит сильнее firefox,
> у которого большая часть гуя суть rdf  + javascript.

Обратите внимание, MicroB (gecko но с нативной мордой) тормозит на н900 существенном меньше чем карманный файрфокс с его XUL (то же gecko + ui на XUL). Разница буквально в несколько раз.

> Вы просто не представляете, как удобно, когда в облике и функциональности
> программе можно без проблем поменять все, что угодно прямо у заказчика.

Я представляю себе что мне неудобно
1) Если телефон дохнет за менее чем сутки, потому что скриптошит тормозит и жрет проц
2) Таскать чемодан аккумуляторов чтобы 1) не происходило.

Чудес не бывает. В CMOS-технологиях каждый лишний цикл означает лишний стекший из батарейки заряд. Чем меньше молотилова - тем меньше кушает проц, RAM, flash, etc. На пониженной частоте с урезанным напряжением питания проц в активном режиме может неделю прокантоваться запросто. А если частоту на максимум - аккум убьется за считанные часы.