Today I came across exactly the same problem as OP in my legacy application that uses RemObjects SDK version 9.7.115.1441. I created .NET 7 (.NET Core) client that connects to RODL based service written in Delphi 7 and provides Windows-1250 encoded string in its interface via AnsiString type.
I used the same code that targeted .NET Framework, but the encoding was mangled in .NET Core application. I quickly found out that .NET Core doesn’t support ANSI encoding by default and that I needed to register provider for that. However setting DefaultStringEncoding on BinMessage instance didn’t work for me.
After further debugging of disassembled code of RemObjects.SDK.dll I discovered that my Intf proxy class has its CloneMessage property initialized to true by default, which creates new instance of message based on original instance that was provided as an argument of proxy class constructor. At tis point I noticed that the value of DefaultStringEncoding property of cloned message instance was a System.Text.ASCIIEncoding.ASCIIEncodingSealed instance. After inspecting BinMessage.Clone() method I found out that DefaultStringEncoding is excluded from cloning process. When I changed proxy’s CloneMessage property to false, the encoding problems were gone.
I consider this a bug, because I think that BinMessage.Clone() should at least copy reference or even clone original encoding.
I didn’t check whether the problem persists in the latest version of RemObjects SDK.
Edit:
Now I see that the bug was filed recently in Converting RODL-based to code-first.