I think one of the main problems is that when you install git for windows, the default setting is to convert LF to CRLF when checking out code. This can cause a bunch of issues if you later try to work with those files within WSL (especially when doing any git-related stuff). I don't really understand why that's the default, or even why it's presented as an option during installation, it's been ages since I actually had issues reading/editing Unix-style files in Windows.
The biggest gotcha on Mac is using git on the default case-insensitive volume. I always create a separate case-sensitive APFS volume for all my git repos to avoid subtle mismatches between the filename git knows about and the filename macOS knows.
The new notepad version was released to non-insiders in Windows 10 1809, so it's still been around for almost 3 years now. I do understand that git wants to maintain the best compatibility, but at this point I would argue that converting to CRLF on checkout is causing more issues than it solves.
Would be weird if platfrom compatibility is measured by making sure once single program works, a program which most of the people using git probably don't even use
It's usually the other way around these days - most Windows apps can handle LF just fine, but Unix apps often cannot handle CR LF. So if you use Windows to generate a text file, things break when you try to use it from WSL.
Is this still really a thing? even notepad can handle LF. I guess the default could still be crlf for some apps.