What problem does this solve or what need does it fill?

The connection between Node and NodeId is quite confusing. I would much prefer just to have one Id type (NodeId) that is either stable through generational arenas or unstable via Slab. Having both is ripe for confusion and adds a layer of hashing and multiple layers of indirection.

I guess we should decide on whether the index is stable or unstable before moving forward. I personally prefer unstable since it's faster, but I'm not sure how most people use their arenas in UI libraries.

If you're a UI dev who uses taffy, then you would save the "LayoutKey" on your node type. In that case, you wouldn't care at all if the ID wraps around. You would really only care about stability if you use Taffy as your ID ground truth and the rest of your library does not support unstable IDs, which I think would be a really weird usecase.

This would allow us to remove the "Allocator" abstraction which removes the atomic operations, which would make Taffy slightly faster.