Это меняет суть дела и значительно. Все программные интерфейсы для приложений другие, штатные приложения переписываются практически с нуля -- по крайней мере, все, что видимо для пользователя, все переписывается. В Maemo 5, кстати, Clutter используется только в одном приложении -- это программа первоначальной настройки. Все остальные приложения не используют Clutter, а пользуются обычным GTK+ (Clutter еще используется оконным менеджером для всяческих эффектов, но это все).
Если посмотреть на Maemo 6 UI Framework preview, который был опубликован на Maemo Summit 2009, то можно увидеть, что подход к написанию приложений там совсем отличается -- в нем не используются стандартные элементы-виджеты, определенные в Qt (как это было со стандартными элементами GTK+ в Maemo 5), а создаются "с нуля" свои элементы на основе QGraphicsWidget, организованных в графическую сцену. Как результат, элементы могут иметь непрямоугольную форму и не обязательно выравниваться параллельно краям экрана.
http://www.youtube.com/watch?v=EURONfIqJ6o показывает некоторые примеры того, что возможно в Qt 4.6 и того. на чем базируется пользовательский интерфейс в Maemo 6. Этот ролик, естественно. не показывает интерфейс Maemo 6, поскольку Нокия будет его беречь от посторонних глаз до самого выпуска устройств на Maemo 6, однако оценить масштаб визуальных изменений в приложениях можно.
Что касается железа и "дрова в ведре", то я бы не был так оптимистичен. Для эффективного контроля энергопотребления все нужно затачивать под конкретную железку и довольно серьезно. Это касается практически всего -- как драйверов, так и самих приложений. В Maemo 5 очень много примеров, когда специально упрощали интерфейс приложений для того, чтобы можно было "влезть" в ограничения пропускной способности памяти, уменьшали сетевую активность, ранжировали приложения по уровням энергопотребления и постоянно контроллировали распределение процессора и памяти между приложениями. Например. все приложения, которые не взаимодействуют с пользователем, автоматически перемещаются в группы с уменьшенным доступом к ресурсам, а отдельные подсистемы (железо) отключаются или переводятся в энергосберегающий режим в соответствии с этими переключениями.
Maemo 5 и N900 в этом не одиноки -- еще при создании OLPC был испытан вариант, когда вся система засыпала-просыпалась сотни раз в секунду. В OLPC экран был энергонезависим от основной системы и если система не меняла ничего на экране и не общалась с пользователем, то она засыпала, а экран отображал неизмененное состояние самостоятельно. Фактически, система могла заснуть и проснуться между двумя соседними нажатиями на клавиши.
Под такое поведение адаптируются и ПО, и железо, при этом их взаимодействие довольно тонкое и плотное. Стоит также понимать, что не бывает железа без ошибок и то, что иногда очень сложно эти ошибки обходить в драйверах, приходится адаптировать и все, что выше, так, чтобы не вызывать ошибки в железе. Насколько я помню, в OMAP2, который использовался в N800 и N810, была аппаратная ошибка, приводившая к тому, что реально добиться 30 кадров в секунду для 800х480 было невозможно. Поэтому Нокия использовала для экрана посторонний чип от Эпсон, который тоже был не очень. В результате, резко выросло количество перемещаемых блоков памяти и даже с оптимизациями получить более 20 кадров в секунду не получалось.
Теперь смотрите -- пользователи требуют работу с разрешением 720p, с кодеками, для которых нет аппаратного ускорения, а только частичная оптимизация средствами различных компонент -- несколькими сопроцессорами, основным процессором -- где еще надо синхронизировать доступ к памяти из разных источников. В результате получается довольно сложная штука, которая тесно переплетает особенности железа, драйверов, промежуточного слоя и самих приложений.
Чудес не бывает, везде кропотливая и тяжелая работа.
