It’s not a consistent change, but for example programs like notepad couldn’t handle \n, but do accept it now. Visual Studio expects certain file types to use \r\n, but accepts others like .gitignore using \n.
Same thing for \ and / in path separators: Microsoft never made a consistent push for it, and it depends on the application.
I'm not sure I would call that "adoption", so much as "compatibility with", since the default line ending produced by Windows software is still almost always \r\n for files created from scratch.
FWIW I think it's a fair point. My view of this is as an outsider only seeing what comes in for review from Windows-using colleagues so maybe I overstated the level of adoption.
I also tried VS code and found that you can configure it to output just the line feed. You could also configure it to append a "trailing newline" which cause an empty line to be inserted at the end upon save. This practically produces valid POSIX text files, though if I wanted to have an empty line at the end of my document it can't tell the difference between that and the so-called "trailing newline".
It ultimately also doesn't really present these files correctly. The last LF is still presented as an empty line at the end of the document. Someone reported that, and they added the option to hide the "trailing newline" to address it, but it effectively only stops displaying it, while you can still navigate to it. I ended up reporting simply that it doesn't handle POSIX text files correctly, describing the problem and the issues with the current attempts at solutions, but it was classified as a feature request and eventually closed due to losing some kind of popularity contest they have for these.
Seemed like such a basic function for a text editor and a dysfunctional response to my report, so quickly gave up on using it.
