There are a number of “systems programming” things which are safe (or at least better-behaved) iff there are no other threads, such as setting the environment as discussed here, fork(), some uses of signals, use of !Sync mutable globals, and probably lots of other things I'm not thinking of.
Therefore, I'm wondering if it would be useful to add to the Rust standard library a mechanism which allows safely invoking some of these things given the unsafe creation of an explicit promise that the process is currently single-threaded, that would be passed as a parameter to the future version of set_var and such. The advantage of this over marking individual calls unsafe is that “not multithreaded” is a global property of the process related to the big picture of the program's control flow, so associating the “here is a property you can't necessarily statically guarantee that I promise is true” with some single high-level scope is more accurate and (slightly) more auditable than sprinkling it about every call site — and that it documents what kind of unsafety is present.
Also, such a mechanism could be used fully safely on targets which inherently have no thread support. (This is not the same as “why not make this construct/function safe if we're on a single-threaded target”, which I've heard rejected before, because it would affect only the site where the promise is created, which is supposed to be rare, not every “leaf” that uses it.)
Disadvantage: this one-size-fits-all mechanism would not address the case mentioned above of threads which exist but aren't doing anything yet (which would be safe for environment manipulation but not for fork(), for example).