There is a big difference between having to create a couple of widgets and having to rename each and every Qt class in your app.

The Dui proposal requires you to change all the top-level UI code. Even though the change seems trivial (Q becomes Dui), it results in having to add complete UI components (an extra one for Dui and probably an extra one for Symbian ^4's UI as well), unless you take certain measures. The measure one takes is to add an extra layer of indirection called a Bridge, with a MyApplication calling either a MyDuiApplication (implemented by DuiApplication), a MySymbian^4Application (implemented by the Symbian ^4 variant of QApplication) or a MyPlainQtApplication (implemented by QApplication). Do this for each and every high-level Qt class that is or might be renamed now or in the future.

Considering that all Qt classes are already implemented as Bridge classes, the obvious thing to do is to implement Qt for Maemo 6 as an extra implementation for the main Qt classes, and to do the same for Symbian^4, and not require each and every developer that wants to target both Symbian^4 and Maemo 6, and possibly other Qt-supported platforms, to create their own set of Bridge classes. That is a complete waste of our time. The commercial realities of mobile development are such that commercial developers do not have the luxury of spending time to fix defects in vendor-provided frameworks. This is something that vendor employees should think very carefully about, because their actions will reflect on the vendors perceived willingness to support commercial third party developers.

Having dealt with the generics, its time for the specifics.

Having device specific classes is of course fine, as long as there are also plenty of generic classes. To make this more concrete, I don't care about the look and feel of the class that lets me set a boolean, as longs as its interface is the same, which means that there should be a generic Qt boolean widget. The reason is that almost all widget classes that I use in my apps will be generic widgets, maybe with a few device-specific ones at places where it matters. If I have to spend days on managing generic widgets (number and text input, radio buttons, sliders, checkboxes, labels), I don't have time for creating that single special widget that makes my app stand out from the competition.
So, create as many Dui-specific widgets as you want, but put the behind a unified Qt API that says, get me a boolean , or get me a number, or get me a bit of text.

The mayor factor on deciding what Qt-enabled platforms your app will have to run on is screen size. In that respect Maemo 6 and Symbian^4 are almost identical, compared to the desktop, notebook and netbook worlds. So changes are that I will need two sets of layout definitions, one for handheld devices and one for big-screened ones. But that is two layout definitions, not three slightly different sets of code.

I don't think it will take years. Implementing the look and feel of the widget might take a year, but defining it's interface will take days, and putting it in the Qt framework won't take that long either.

By that time the mobile OS war will be over. By having a unified Qt API it might take slightly longer for the platform to become available, but the upside is that the unified mobile Qt platform will be a lot bigger from the start, combining both Maemo 6 and Symbian^4. And as a bonus, you get the additional Qt platforms for little extra work, and not for much extra work.

Java had problems because vendors deliberately introduced their own extensions and incompatibilities. Further, for very small screens you do need exact pixel placements. That isn't a problem with mobile screens as big as they are now, for standard components.

Hiding Dui behind Qt is the way to make things cheap. Only for the Dui classes that do not have a generic Qt equivalent do you need it. DuiApplication, DuiWindow and such are not needed at the third party API level.