YES, you did understand it correctly. This is the VCL and its documentation which are broken. Your confusion does perfectly make sense!
In the Delphi 2009+ implementation, you have to use AsString property for AnsiString and AsWideString for string=UnicodeString.
In fact, the As*String properties are defined as such:
property AsString: string read GetAsString write SetAsString;
property AsWideString: UnicodeString read GetAsWideString write SetAsWideString;
property AsAnsiString: AnsiString read GetAsAnsiString write SetAsAnsiString;
How on earth may we be able to find out that AsString returns an AnsiString? It just does not make sense at all, when compared to the rest of the VCL/RTL.
The implementation, which uses TStringField class for AnsiString and TWideStringField for string=UnicodeString is broken.
Furthermore, the documentation is also broken:
Data.DB.TField.AsString
Represents the field's value as a string (Delphi) or an AnsiString (C++).
This does not represent a string in Delphi, but an AnsiString! The fact that the property uses a plain string=UnicodeString type is perfectly missleading.
On the database point of view, it is up to the DB driver to handle Unicode or work with a specific charset. But on the VCL point of view, in Delphi 2009+ you should only know about string type, and be confident that using AsString: String will be Unicode-ready.