[bug / unclear specs] Strings starting with '1' (0x31) are identical to strings starting with '𑁒' (\U00011052)

[Unknown6656]

Context

I am developing a small library, in which custom string to double parsing is employed. The parsing function also takes care of "unconventional" unicode symbols, i.e. numbers prefixed with \u02D6/\uFE62/\uFF0B/\u208A/\u207A instead of +, etc.

Behaviour

I noticed the following (possible) bug when filtering for unicode minus/hyphen signs:

string one = 1.ToString();
bool starts = one.StartsWith("\U00011052"); // 𑁒
bool equals_inv = one.Equals("\U00011052", System.StringComparison.InvariantCulture);
bool equals = one.Equals("\U00011052");

System.Console.WriteLine(starts);
System.Console.WriteLine(equals_inv);
System.Console.WriteLine(equals);

prints the following output:

True
True
False

(sharplab)

Unclear Specs?

Now, I get that https://www.compart.com/en/unicode/U+11052 defines the codepoint as "Brahmi Number One", however, I'm not sure why '1' and '𑁒' are considered equal due to their different optical appearance. Furthermore, the documentation on String.StartsWith(String) does not document the varying behaviour in regards to String.Equals(String) when not supplied with an explicit value for StringComparison. (see https://learn.microsoft.com/en-us/dotnet/api/system.string.startswith?view=net-8.0#system-string-startswith(system-string))

Question

Would it be possible to clarify this behaviour somehow in the C# docs? I mean either the comparison on non-latin number symbols or the explanation of the following behaviour:

string A = "1";
string B = "𑁒";

_ = A.StartsWith(B); // True
_ = A.Equals(B); // False

[huoyaoyuan]

The behavior of string operations belongs to dotnet/runtime repo. It's not a part of the language.

It is an inconsistency that Equals defaults to ordinal while StartsWith defaults to culture-aware. Unfortunately, this cannot be easily addressed due to the huge compatibility debt for 25 years. There was discussion about helping this at dotnet/runtime#43956.

Meanwhile, you can use globalization analyzers to help you specify behavior explicitly, or simply check the source code at source.dot.net about the option-less overload. Documentation improvement requests should be sent at dotnet/docs.

[Unknown6656]

Thanks, I submitted an issue to dotnet/runtime (dotnet/runtime#97544) and I'll transfer it to dotnet/docs if needed.