Version: 10.10.0
Platform: Windows 10

By checking all envs in process.env with assert.strictEqual, ASCII characters can make the test to get flaky results, as they will be "equal" but with different characters.

Example:

AssertionError [ERR_ASSERTION]: Input A expected to strictly equal input B:
  expected - actual

- 's´┐¢b ago 25 21:24:21 2018'
  'sáb ago 25 21:24:21 2018'

That is from ChocolateyLastPathUpdate, can be the env and it has non ASCII characters, by getting the date locally, but I guess that ChocolateyLastPathUpdate can be there or no, aswell any other env with non ASCII characters.
This will happen with any assert test, as Object.is() treat strings this way: both strings of the same length with the same characters in the same order(from mdn), I thought about making it a feature request for ASCII support in assert when using it with strings but it looks very specific and I guess that it can not be normalized in all scenarios.

The test could not do assert.strictEqual if safeGetenv(oneEnv) or process.env[oneEnv] has non ascii characters or have a "safe value" of strings that can be not equal, before getting an AssertionError.