> Atomic refcounting works, however, because the access to heap memory is > protected by atomic operations even when the ref variable goes out of the > scope, and thus prevents races.
It's very important to note that _only_ protects against races in the atomic count, _not_ data races in general. In my opinion, relying on just atomic-ref's is an easy way to lure developers into a false sense of security like is seen in Golang. Essentially you have one of: read only data (atomic sharedptr wrappers), movable data with single ownership (Isolate[T]), or you need some sort of locking mechanism around the data in "atomic chunks" (locks).
