I would agree with Öö Tiib’s remark
That option is perhaps for
compatibility with some old legacy
pre-wchar_t code.
Having in mind that Qt is ported to many different platforms (including embedded systems), some of them not having a decent C++ compiler, I would guess that this switch is just to make it possible to compile Qt on those platforms. I mean it’s probably not something that Qt relies on to work correctly. If it were the case it would mean that Qt’s design is deeply broken in my opinion. So option 1 should work.
Having said that I would definitely recommend choosing option 3 because
wchar_tgives you almost nothing in
regard to i18n- as you noticed Qt has very capable string class
which makes i18n an easy task (see
Internationalization with Qt)
You might take a look at results of searching for wchar_t on qt-interest@qt.nokia.com list, ask your question there and talk to Thiago Macieira on freenode.net #qt irc channel where Thiago is very active.