The bug mentioned an alternate solution strategy, which was "replace the mode at the end of the build". Did you consider and discard that? Is this a better option?

I was the one who first noticed the VT100 issue because I use cmd for most things. I typically believe the simplest solution that resolves the problem is the best solution, as it is least likely to have hidden bugs, and this simplifies the code rather than potentially leaving some issue open with a build that fails to reset the mode after some unusual sequence of events. I tested that this did not reintroduce the issue I'd seen by building something with the bootstrapped MSBuild.exe. If the problem remains resolved, and the code is simpler, I think it is the best solution.

Looks legit. What was the intent behind disabling it originally?

As I recall, I found code that claimed to resolve the VT100 issue. I put it into MSBuild and tried testing it, and it seemed to work properly whether or not that parameter was present. Since whoever wrote the snippet I'd found online seemed to think it was important, I figured there was some case I hadn't tested where it would be useful, so I left it in.

Does leaving ENABLE_VIRTUAL_TERMINAL_PROCESSING on have no cost to subsequent CLI interactions or user programs in dotnet run? Wouldn't it mask the need to set that in the actual application if it emits VT100 codes?

For instance, is this behavior difference acceptable, even if we fix the newline situation?

For clarity, is your concern that it converted \x1b[31m into "change the color to red"? Honestly, I don't know why someone would want to see \x1b[31m.

But cc @baronfel for a proper opinion.

Yes, that's the concern. It's possible that it's explicitly outputting that for Reasons, but I would say my concern runs the other way: if you run it with dotnet run and it always renders the VT100 codes instead of spewing console gibberish, you'll likely be surprised when the deployed app instead spews gibberish.

Correct - @rainersigwald has the scenario nailed here. MSBuild should return the state to whatever it was before invoking MSBuild. Other applications shouldn't have to alter their behavior based on whether or not they were run after MSBuild in a dotnet run scenario.

Ok, that's more reasonable than wanting random codes in your output. I'd suggest that's perpendicular to this change, as this change is specifically for newline and (in my opinion) should happen regardless. I can try to put something together to resolve that issue as well.