.I agree, that Ogre is not an GUI Library and neither the Ogre itself nor the GUI used in the samples need to support Unicode
As Ogre is using Ogre::String to identify objects and so, I even think that Ogre::String should not support Unicode (I think that's the reason, while it's not supporting Unicode until now). I would even go a step further and suggest to remove the optional wchar_t version of Ogre::String, especially as it isn't compilable because of the Literal incompatibility (see http://www.ogre3d.org/forums/viewtopic.php?f=2&t=47586)
But what I think we need is a support of Unicode Paths as currently, some sort of platform dependent workarounds are needed: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=76191
Se we see it is possible to handle unicode path, but not in an very object oriented way
My suggestion is to implement some kind of FilePath class (something like the path class from Boost filesystem, or maybe even simply using boost::filesystem::path).
This FilePath could be used everywhere were paths are handled inside of Ogre. For example when loading a plugin or resource using some kind Manager accessing the hard drive, you would give Ogre an instance of Ogre::FilePath without event thinking, whether the Operating system is supporting Utf8 or so.
Internally, when calling a Windows API code, Ogre::Path::getAsUtf16() would be called, while when using Unix api code Ogre::FilePath::getAsUtf8(). The user of Ogre wouldn't even need to know, that soething like Utf8 or utf16 even exist
