No that was not a breaking change. Panicking is a correct implementation of unreachable_unchecked.
However, the much more problematic code was the one that used mem::uninitialized to create values they actually wanted to then initialize and worth with. There we had an alternative available when mem::uninit got deprecated, and a lint to find definitely bad uses of mem::uninit, and a lot of other effort, and still you can find a bunch of MaybeUninit::uninit().assume_init() out there where people couldn't be bothered to actually fix their code. And that was from one unsafe API to another, here we are talking about code that is currently nominally safe!
Porting code away from set_var to not using the environment is, I think, less local and hence more tricky than porting from mem::uninit to MaybeUninit. So if the mem::uninit story teaches us anything, I think it is that we do need to provide an easy target to port to, like a Rust shadow environment.
No, that would make it entirely unsuited for its one and only purpose -- to port existing code.
The shadow environment is a thread-safe global HashMap<OsString, OsString>, there is no need to expose its lock. We don't need transactional access to that global map. Even if there are multiple threads, as long as they all work on different env vars, there is no race condition.