This arose when I was trying to have a substitution which invoked a python script P, and that python script tried to invoke clang-cl (or even cl). Since we invoke P with a custom environment, it doesn't inherit the environment of the parent, and then when we go to invoke clang-cl, it's unable to find the MSVC installation directory. There were many more I could have passed through which are set by vcvarsall, but I tried to keep it simple and only pass through the important ones.
I don't think that ever actually happened, or at least I never observed it. The real behavior change is that we're now passing through "LIB", "VCINSTALLDIR", "VCToolsInstallDir", "VSINSTALLDIR", "WindowsSdkDir", and "WindowsSdkVersion", whereas before we were not propagating them into the child environment at all. clang-cl reads these, so it could have an observable impact on clang-cl (but any observable impact should be beneficial, since before it would actually just fail if a test tried to include a system header or link against a system library)
At least for clang tests, tests reading system libraries are usually a bug -- tests are supposed to be hermetic, cross-platform, etc. It sounds like now it's easier to accidentally use a system header?