No longer experimental

So we have a concurrent LIFO stack, where the "concurrent" means (among other things) that races must be handled gracefully. Whatever is push()ed, anyone doing a pop_all() must be prepared to accept, and in pretty much any order. So if this is a stack of Pokémon, then the caller of pop_all() must be willing to accept a Pikachu (or a Blastoise or a Squirtle or...) as well as a Jigglypuff. But the caller need not worry about popping an ewok, gremlin, or whatever else, again assuming that only Pokémon are ever push()ed. And, given that this is in fact a stack of Pokémon, nothing but Pokémon should ever be push()ed. The question before us is how to make the language implementation deal gracefully with this.

And one concern is that the language implementation might notice at push() time that the top of stack is in fact a Jigglypuff, and somehow keep Jigglypuff-specific state associated with that element all the way through to the time that this same block of memory (now a Pikachu) is popped. As you say, this would be bad.

One hope is that something similar to the exposure API would allow the LIFO stack to mark the ->next pointer as having unknown provenance, keeping in mind that the actual provenance is subject to change until a successful compare_exchange_weak() operation. We need this reprovenancing to be automatic in C and C++ (hence the proposals involving angelic provenance), but Rust has the advantage that almost all authors of any Rust code are not only still alive but also have an excellent chance of remembering whether or not they ever coded a concurrent LIFO stack. So in theory, one possibility in Rust is to change all existing LIFO stack code to (say) pass a pointer stripped of provenance to set_next(). In practice, I have no idea whether this works for the Rust language or its modeling tools (such as Miri, for which this sadly seems unlikely). Another possibility is a special compare_exchange_weak() operation that resets the provenance of the "old" pointer, though this only works for stacks that have the ->next pointer exposed to the LIFO stack, not for ones using set_next() and get_next().

And to your last point, I too hope that this is somehow not a problem in Rust. But hope springs eternal, and mere hope is insufficient to consistently produce correct concurrent code. ;-)