There will not be a circular dependency issue whatsoever. The stdlib will just have to have its own internal watered down version of Atomic for the niche use cases it has.
This would be true, however this sort of proposal is quietly walking along the line of the whole concept of "interior mutability" (Interior mutability - The Rust Reference) which is something that helped bring inline atomics to Swift. Atomic is an address type. When you pass a value of Atomic around, you pass a pointer to it, very similar to passing a reference around with classes. Classes can mutate their storage while being just a let because like I mentioned you pass a reference around. The key difference, which is what I think is confusing, is that these things are inline instead of storing a pointer inline. When you store a value of Atomic in your struct, your struct becomes an address type who also is passed around by pointer. Because we always have an address to our atomic (and it is marked as raw storage) we can "mutate" the underlying value without needing var.
In a future proposal, we would like to introduce a type like Cell which would discuss interior mutability more in depth and introduce a way for everyone to make use of this sort of behavior.