The only winning move is not to play. Mapping libraries, even with source generators, produce lots of bugs and surprising behavior. Just write mappers by hand.
So far, there have been no surprises, and the library warns about potential issues very explicitly, I quite like it.
Of course, if it's just a handful of fields that need mapping, than write manually is the way to go, specially if said fields require a custom mapping, where the library would not facilitate.
It was meant to enforce a convention. Not to avoid the tedium of writing mapping code by hand (although that is another result).
This describes more than half of .net community packages and patterns. So much stuff driven by chasing "oh that's clever" high - forgetting that clever code is miserable to support in prod/maintain. Even when it's your code, but when it's third party libs - it's just asking for weekend debugging sessions and all nighters 2 months past initial delivery date. At some point you just get too old for that shit.
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.
The compiler knows what you're doing. A keyword like 'field's inside a function's braces just isn't valid. Putting 'field' after a type name in a variable declaration makes as much sense as 'private int class;'
That said, they will also throw compiler warnings in console during build if you are using an all lowercase word with some small number of characters. I don't remember the exact trigger or warning, but it says something like "such words may be reserved for future use by the compiler" to disincentivize use.