r9154 removes filename UTF8 tunneling in document handling

We need to decide if we want TCHAR PathString or not; if we don't, modifying CTreeCtrl.h doesn't make much sense, as it's used in PathString-related contexts only. So it's either both or none.
For the same reason I'd also not modify the file dialogs if PathString stays WCHAR.

Agreed.
I tried modifying CTreeCtrl (and related) once, and it resulted in a rather huge mess if PathString stays WCHAR.
IF when make PathString TCHAR, we would probably have to modify various places that currently assume PathString::AsNative() is WCHAR-based. This would either be a huge single commit, changing all usage sites, or would gradually introduce #ifdef around these assumption which could again be removed when we actually do the switch of PathString to TCHAR. Both options appear like a lot of work to me.

Another option might of course be to just completely remove support for ANSI builds. This would cost us some compile-time string type checking though.

Removing explicit WCHAR support in FileDIalog would allow us to use CFileDialog again, which has the advantage of automatically using IFileDialog when available rather than the classic GetOpenFileName/GetSaveFileName. This in return has the advantage that specifying a hook procedure for selection changes (like we do when "preview samples in file dialogs" is checked) does not enforce the "classic" pre-Vista file dialogs.

PathString is TCHAR based as of r9657 .
FileDialog uses CFileDialog again as of r9670 through r9692 (Saga Musix).
CTreeCtrl.h is gone as of r9746 (Saga Musix).

COM GUID functionality is still std::wstring, however the COM API is based on OLECHAR, which is WCHAR even in ANSI builds, thus it does not make much sense to change that area.

Are there any other bigger areas that still need to get converted?

Any usage of mpt::ustring in the UI leads to using the widechar WinAPI functions, but I don't think that's necessarily an issue that needs to be fixed. The only time this is going to be relevant will be if we switch to a GUI toolkit that prefers utf8 strings over wide strings, in which case we have to remove the WinAPI functions that are being called anyway. So I'd leave these sites as-is and consider this issue to be resolved.

There are probably still some minor places that could use cleanup.
However, not even searching for "W(" does show anything big at all by now.
PluginBridge is still mostly WCHAR based, I do not think it makes much sense to change that though.
Closing the issue.