It is what I needed 100% of the cases where I so far used set_var/remove_var (which is mostly inside cargo-miri). Refactoring that code to remain safe when those functions are unsafe will be annoying -- not terrible, and if they had been unsafe to begin with that's what I would have done, but given that we had (and have) safe environment functions, of course I wrote my code to match.
What do you think are people going to do in that situation? I think a significant fraction of them will just add the unsafe block and be done with it. For many of them the unsafe premise (no other threads) might even be correct, for some it won't. So the result of your proposed plan is, in the optimistic case, a bunch of existing safe environment-touching code becoming unsafe. In the pessimistic case, that code becomes unsound.
I understand your objection to a Rust shadow environment, and I don't like it either. What I am missing is a realistic alternative. What is your plan to deal with this problem I am predicting? I am astonished that many people here seem to think that all of the existing users of set_var/remove_var will carefully ensure that there are no other threads before adding unsafe blocks around their existing, working, code. I am equally astonished about the proposal to declare a non-trivial fraction of existing, working, code unsound without any easy migration path. This is even more astonishing given that you are are usually very reluctant about subtle forms of UB.
I am fully in favor of deprecated_safe. But given that we have 7 years of code that were written assuming those functions are safe, I think it's not enough.
