Note that how we set MSYS ignores env/env_remove calls

This problem can be avoided by a design that doesn't create the
assumption that such calls would have an effect, or that prevents
them from being made (e.g. a builder funtion), or by accounting for
and honoring them (which may involve reimplementing a fragment of
the Windows API based case-folding that `std::process::Command`
uses). But none of these approaches really seems overall better
than what we are doing now. So for now, keep the design but note
this one confusing spot.

This is a private function, so I've just commented by where the
relevant logic is, rather than using a `///` comment.

Author: EliahKagan

tests/tools/src/lib.rs

@@ -594,6 +594,9 @@ fn configure_command<'a, I: IntoIterator<Item = S>, S: AsRef<OsStr>>(
     args: I,
     script_result_directory: &Path,
 ) -> &'a mut std::process::Command {
+    // For simplicity, we extend the `MSYS` variable from from our own environment. This disregards
+    // state from any prior `cmd.env("MSYS")` or `cmd.env_remove("MSYS")` calls. Such calls should
+    // either be avoided, or made after this function returns (but before spawning the command).
     let mut msys_for_git_bash_on_windows = env::var_os("MSYS").unwrap_or_default();
     msys_for_git_bash_on_windows.push(" winsymlinks:nativestrict");
     cmd.args(args)