All of the caveats basically boil down to "if you need to access the private backing field from anywhere other than the property getter/setter; then be aware it's going to have a funky non C# compliant field name".
In the EF Core and Automapper type of cases, I consider it an anti-pattern that something outside the class is taking a dependency on a private member of the class in the first place, so the compiler is really doing you a favor by hiding away the private backing field more obscurely.
I'm surprised there isn't something pseudorandom thrown in for good measure – like a few digits of a hash of the source file.
The trick with using characters which by definition are not allowed inside variable names, "<" and ">", should be sufficient no?
I believe the reason for this is that it would break deterministic builds.
dotnet build is’t deterministic as default. Never has been.
Except deterministic builds have been the default since 2015?
Serialization is a pretty good cause.
Serialization shouldn’t be dependent on the name of the backing field.