Consider some code that is looking for an env var that it knows should be valid UTF-8. It would be tempted to use std::env::vars() for this:

let value =
    std::env::vars()
    .find_map(|(key, value)| if cond(key) { Some(value) } else { None })
    .unwrap();

(It doesn't know the exact name of the env var, hence the need to enumerate every env var and test the key with cond, rather than just using std::env::var().)

But this will panic if an unrelated env var that isn't convertible to String happens to be enumerated first, because Vars uses .into_string().unwrap() on both OsStrings that it gets from VarsOs. This behavior is documented on std::env::vars(), so it's by design.

So, to be robust against this failure mode, the code has to use std::env::vars_os() and test for String-iness itself:

let value =
    std::env::vars_os()
    .find_map(|(key, value)| {
        let key = key.into_string().ok()?;
        if cond(key) {
            let value = value.into_string().ok()?;
            Some(value)
        }
        else {
            None
        }
    }).unwrap();

Env vars are almost always out of the hands of one's code, and can come from any number of sources even the user running the program may not account for. So it seems to me that std::env::vars() as it's implemented today is a trivial way to crash unnecessarily and should never be used.

It would be nice if it skipped non-UTF-8 env vars instead. Or, if it's necessary to preserve compatibility with the current behavior (which it has had since 1.0), there was a new function that did (std::env::vars_utf8_only() ?)