Looking through the source of 2.8.10 it appears that unicode is possible with that version too.
In the Windows world, "unicode" means UTF-16 (wchar).2.8 has two build variations, ANSI and UTF-16 (unicode). The UTF-16 version is the "unicode" version provided in the Debian package. I believe 2.8 and its UTF-16 build labelled simply "unicode" has been the source of build problems described in the forum. We were previously using 2.8 ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell. We cannot compile with UTF-16.
2.9 has only one version, UTF-8. On Windows, we set the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces with us in UTF-8. On Linux I assume the codepage is already UTF-8. By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for UTF-8 internationalization.
Make sure you read build-unix.txt and configure wxWidgets using the configure parameters given.
Curious, why is it incredibly hard to provide wxWidgets 2.9.0? If you mean for users, that's why we static link it.
It's unfortunate that we require so many big dependencies, but we need them all. At least on Debian/Ubuntu, all but wxWidgets are available as packages. Eventually they'll provide a 2.9 package.