I think there's a lot of "the devil is in the details", here, and I'm going to be respectful enough to not start a bunch of "why don't you just…". It does soun

I think there's a lot of "the devil is in the details", here, and I'm going to be respectful enough to not start a bunch of "why don't you just…". It does sound like a thing where if you'd written this in C++, then you could have done it much easier (which is my experience), and then either also, or later on when the state of the invariants are no longer in your working memory, one of those invariants would be violated and memory start corrupting (also my experience). E.g. in a C++ vector you can push_back() without invalidating the iterators iff there's enough capacity in the vector. Though if some code saved the "end()" iterator (e.g. concurrent for_each), that's broken. std::vector doesn't permit that use case, but does not prevent it. I prefer it being prevented. I would consider the extra work to be worth not finding that problem in production, later. Ideally what you want could be accomplished by just (oh no, there I go) finding a single place to punch a hole, put an "unsafe" there, and explain why it's actually fine to create some inner mutability or whatever is needed there. The huge complexity baggage, and the amount of working memory you need to reason about async, is unfortunate though, and I won't defend it. But at least it fails closed if you get it wrong.