Indeed, that's why I suggested making it thread-local. However as @RalfJung said:
its one and only purpose -- to port existing code.
I didn't think of it in this way before but now realized that fixing these issues is best done with direct env configuration of Command or analogous constructs in FFIed libs anyway. So maybe it's not really the best either. I guess the doc should say it out loud.
The reason I suggested thread local is I came across a PR that wanted to use external command-calling library together with set_var. Ofc I immediately pointed out that this was bad in multithreaded code. I got told that library-native approach didn't work. In cases like this it'd be really helpful to have thread-local environment. It would be possible to have both (thread local having priority over global) but maybe it's too much and the library needs to be fixed anyway (if it's really broken and not some usage mistake). Image may be NSFW.
Clik here to view.
Panicking is a correct implementation of
unreachable_unchecked.
It is UB-correct but often people use unreachable_unchecked because they don't want the branch there (enum matching). By reintroducing the branch the code is "broken" in the sense it no longer works as they intended and explicitly wrote.
Agree with the rest of your points, transition to a sound solution should be as easy as possible.
