I don't understand the problem:
FPC has about the richest set of string types available and to be more specific NTFS has never been any problem under Windows. There really is no need to recompile the whole with FPC_OS_UNICODE and it is not a workaround in that sense. The Unicode API's are fully accessible by means of the UnicodeString type, which is a Windows compatible UTF16 reference counted string type compatible with Delphi or C#.
Can you give us a small example where you ran into trouble?
I guess you are simply looking for a modeswitch
and indeed that is there:
Use {$modeswitch unicodestrings} or even better (since you are developing for Windows) use the {$mode delphiunicode} which switches the default string to a Delphi 2009+ compatible Unicode16 string.
"string" becomes an alias for "unicodestring"in these cases and the "XxxxW" windows Api's are called.
Also, Lazarus has an intermediate solution based on UTF8 by default.
If you ran into trouble, the most likely that happened is insufficient reading of the very good documentation.
There ARE good reasons to recompile with FPC_OS_UNICODE but these are not specifically related to Windows API's or NTFS (which is a special case of the former).