I recently worked with Dermot Malone, the Responsible Engineer for this bug report.

The fact is the described problem persist as explained in the Description field of the bug report, running snv_70. But I must say I found something recently: as of now, I used the default C locale. But after reading this documentation (go to Unicode Locale: en_US.UTF-8 Support), I decided to try the en_US.UTF-8 locale, directly chosen from the dtlogin screen... and found that I can now have a similar English environment as before (using C locale), while supporting accent and circumflex characters from applications which support this locale (for example the GNOME Terminal, or Mozilla Firefox). Hum, I just find a little big curious that most of accent characters (say 'é') works properly using the C locale, but that I need to set an other locale to be able to use the circumflex characters (say 'ô').

As a matter of interest, Dermot ask me why I didn't use the fr_FR.UTF-8 locale. Here is my answer:

Well, I am a French guy, but systematically install English operating systems, and use the default C locale. In IT, English is _the_ standard, and all things (manual pages, messages, format strings, etc.) are all homogeneous this way. As a side note, I am sure not to encounter the problems found on RedHat Linux systems when the default locale is not properly supported by the OS sub-systems themselves (the RC scripts generally sets the LANG=C (or something like that) for 'grep', 'sed' and 'awk' for example), or some third party products (such as the IBM TSM Backup Archive client).

Now, using the en_US.UTF-8 locale on Solaris and Solaris Express, I can have best of both worlds: a fully functional (and supported) English environment, and be able to use extended characters specific to my language.