If there is a single thread then it did happen. If there isn't you actually don't know if "it happened" - it may have been overwritten in the other thread right after you wrote (even with "safe" locking), so the behavior already is terrible. I'm not saying my suggestion is great but seems to be least disruptive.
@RalfJung
It certainly is not a great outcome. I reminds me of situation with mem::uninit which some crates used as a (subjectively horrible) hack to implement unreachable_unchecked. Turning it to panic was technically breaking change even for arguably questionable but technically valid code (I believe; correct me if I'm wrong), yet the decision was to do exactly that. And I think it was the least bad decision.
set_var affecting shadow environment is bad but it may be least bad decision. I'm personally not sure but would like to see some comparison with historic cases (were there other?) and some nice argument why it's different this time.
But if the decision is to keep set_var as-is and add shadow environment I propose to make shadow environment thread local for the exact reason I explained above. Or perhaps allow explicit locking. Actually, maybe not being able to hold a lock while you run Command is a good argument that even if there was no UB around setting global env, it's still very impractical.
