This solves the UTF8ToConsole issue and brings me back to the actual problem that I see in fpspreadsheet. The issue occurs in the unit test "formulatests" of the Excel function "LEFT("Ändern",3)" which should return the first 3 characters of the string "Ändern"; a string mismatch is reported for the argument passed to the LEFT function if the test suite is compiled with fpc 3.1.1 (EnableUTF8RTL off). Again no problem with fpc 2.6.4 and with fpc 3.1.1 (having EnableUTF8RTL active).
I don't know what your code's looks like, but as far as I've tested (only some basic tests), my recommendations would be (if the current situation doesn't evolve):
1/ Question to keep in mind when you are coding with FPC 3.0+:
. what is the (static) code page of my string variable (any 1-byte kind of string, like "string", "ansistring", "utf8string", ...) ? Which includes: what does CP_ACP(=0) really means in my case (mainly in no-utf8rtl and utf8rtl cases) ?
. what is the type of the text data encoding inside my string variable ?
As soon as you're
lying (i.e. code page <> real text data encoding), you'll get a good chance to get in big troubles with Free Pascal, sooner or later (especially at run-time).
2/ Clearly, the new version of Lazarus (Lazarus 1.5+ with FPC 3.0+) is definitively oriented Unicode: UTF-8, for being precise. So, don't use anything else than utf8 strings in your code.
If you have to deal with "external" text data encoded differently, convert them immediately in UTF-8 just after getting them from the "external" source, or just before putting them back to the "external" source. And don't use anything than these utf8 strings in your code.
It may sound "hard", but I'm afraid that expecting no issues when porting existing code form Lazarus 1.4/Free Pascal 2.6.4 to Lazarus 1.5+/Free Pascal 3.0+ is, IMHO, unlikely . Not unless you never, ever used anything than utf8 strings and text data in your code.
However, please consider that they are only recommendations from a "Unicode newbie" ...