Given documentation for string.StartsWith and this snippet (targeting .net core 2.x): 
This method compares the value parameter to the substring at the beginning of this string that is the same length as value, and returns a value that indicates whether they are equal. To be equal, value must be an empty string (String.Empty), must be a reference to this same instance, or must match the beginning of this instance. This method performs a comparison using the specified casing and culture.
https://learn.microsoft.com/en-us/dotnet/api/system.string.startswith?view=netcore-2.1
static void Main(string[] args)
    {
        var unicodeCtrl = "\u0000";
        var str = "x";
        Console.WriteLine($"Is it empty     => {unicodeCtrl == string.Empty}");
        Console.WriteLine($"Lenghts         => {str.Length} {unicodeCtrl.Length}");
        Console.WriteLine($"Are they equal  => {str == unicodeCtrl}");
        Console.WriteLine($"Are they ref eq => {Object.ReferenceEquals(str, unicodeCtrl)}");
        Console.WriteLine($"Contains        => {str.Contains(unicodeCtrl)}");
        Console.WriteLine($"Starts with     => {str.StartsWith(unicodeCtrl)}");
    }
It produces expected result on Windows:
Is it empty => False Lenghts => 1 1 Are they equal => False Are they ref eq => False Contains => False Starts with => False
but when run on Linux (via docker) the result is:
Is it empty => False Lenghts => 1 1 Are they equal => False Are they ref eq => False Contains => False Starts with => True
Would you consider this a bug?
Platform dependent behavior? 
Please note I'm not asking how to make it work (change to str.StartsWith(unicodeCtrl,StringComparison.OrdinalIgnoreCase))
but rather if you believe this is intended/correct behavior.
Edit: I tried to match my local locale on Linux, but it did not make a difference. I tried default C (en-US-POSIX) and pl_PL.UTF8
 
    