The text property (TMSFMXRichEditor.text) returns also the unicode BOM, which should not be, and I believe thats the cause of the stream issue too.
So when the editor contains a unicode text, a=nf I get it with s:=TMSFMXRichEditor.text, s contains #$FEFF'Hello World'#$D#$A instead of 'Hello world'#$D#$A
It is unclear how you do this. There is no overload of the TMSFMXRichEditorHTMLIO.Load() function where you can specify the encoding, so how you use this is unclear. Also, I tested TMSFMXRichEditor.Text: string and checked the byte stream returning from this propery and it doesn't contain a BOM marker (even after first loading a text file with BOM marker)
To replicate, drop TMSFMXRichEditorMiniHTMLIO and TMSFMXRichEditor on a form and execute the code below. Check what you get in the variable 's' and whats in the text file. I get the unicode BOM in 's' and the textfile has a questionmark. As you see, there IS an overload function to select encoding...
Thanks for this extra clarification that helped us trace & solve this issue. It came down to a problem with the Delphi class TStringStream but we've implemented a workaround for this issue. The next update will have this fix.