I see what you're saying... but Nim's design is different. There is no invisible synchronization for globals. They are unsafe if you mutate them (usual "shared xor mutable" disclaimer). If you are going to mutate shared state, you must take appropriate precautions (locks, memory barriers, etc.)
Globals are "bad" by design. My understanding is they are provided as a convenience, instead of passing around shared context around all your application. Globals are (typically) initialized at startup and therefore differ from other thread-specific allocations in that their lifetime is the scope of the application (ie.., globals aren't owned by any thread.) It's also unsafe to put any thread-owned GC'ed object into a global for that reason. If the thread ends, the object would be reclaimed and you'd be left with a potential illegal access. Instead, if you want to dynamically store things in a global, you currently have to use manual memory management (e.g. allocShared) in addition to thread-safety precautions.
