Do I have to use L each time I pass a cosntant to ReadString?
s = MyIni->ReadString (L"ü", L"SomeEntry", "");
The Embarcadero example doesn't say so, but they also don't use non-ASCII characters in their example.
In C++Builder 2009 and later, the entire RTL is based on System::UnicodeString rather than System::AnsiString. Using the L prefix tells the compiler to create a wide string literal (based on wchar_t) instead of a narrow string literal (based on char).
While you don't HAVE to use the prefix L, you SHOULD use it, because it invokes less overhead at runtime. On Windows, constructing a UnicodeString from a wchar_t string is just a simple memory copy, whereas constructing it from a char string performs a data conversion (using the System::DefaultSystemCodePage variable as the codepage to use for the conversion). That conversion MAY be lossy for non-ASCII characters, depending on the encoding of the narrow string, which is subject to the charset that you save your source file in, as well as the charset used by the compiler when it parses the source file. So there is no guarantee that what you write in code in a narrow string literal is what you will actually get at runtime. Using a wide string literal avoids that ambiguity.
Note that UnicodeString is UTF-16 encoded on all platforms, but wchar_t is used for UTF-16 only on Windows, where wchar_t is a 16-bit data type. On other platforms, where wchar_t is usually a 32-bit data type used for UTF-32, char16_t is used instead. As such, if you need to write portable code, use the RTL's _D() macro instead of using the L prefix directly, eg:
s = MyIni->ReadString(_D("ü"), _D("SomeEntry"), _D(""));
_D() will map a string/character literal to the correct data type (wchar_t or char16_t, depending on the platform you are compiling for). So, when using string/character literals with the RTL, VCL, and FMX libraries, you should get in the habit of always using _D().