It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

Marked as X-Controversial due to the architectural implications, but I quite like the core strategy and really want this functionality.

I have not looked very closely at the implementation yet, but here's a few thoughts.

This is probably the best way to implement component scopes. In my own ecs engine, I've implemented something similar to the chunked tables, and it was very much not worth it. Removing, scoping, and re-adding a component is probably also too slow, would create useless or maybe even invalid (with archetype invariants) archetypes, and maybe cause hook issues. Either hooks will run, making the previous sate unrecoverable, or the scope will have an invalid world state–this is general form of the relationship problem you mentioned.

Even in terms of the objective, I'm not convinced this is the right way to go. This is definitely not my decision, but what I've noticed is that these scope functions get really messy and are IMO not good practice. I didn't like resource scopes because they were limiting and promoted lots of nesting. I almost always just did a run_system_once and Commands with a closure or something. With components too, I feel like this could lead to a lot of bugs in user code. Now, every helper function a user makes needs to know if it's running as part of the scope or not, and if so, it may need a special way to handle the scoped entity. (Ex: The scope uses a helper function to sum up all the health components, but the scoped entity has a health component and is missed. Now that function needs to know if its running in a scope or not.) Maybe that's rare; I really don't know, but I don't like how much danger this allows users. I'd much prefer making an easier way to scope safe access to QueryParams.

At a conceptual level, I also think this might be unsound. As an example, what if you scope access to a component value and then clear the world? Now the old copy has been dropped, but you still have a mutable reference to a copy of a now dropped component! That's a big deal if the component has a Vec or something; now its a double free. And you can't just mem::forget the new one since maybe the vec was changed and the allocation moved. To fix this, you'd need some way of knowing just from &mut World if a given component is scoped, and I think tracking and checking that information everywhere is probably more trouble than it's worth. Unless I'm missing some way around this. (Maybe do the add and remove idea, but that has it's own problems. Or maybe add a new hook mode to fix those? Idk.)

I know I said this is probably the best way to do component scopes, and I stand by that (unless you come up with something better 👀 ). All other ways of doing this that I can think of come with massive performance issues and correctness concerns. I think this is the most useful way of doing it; it just needs to be unsafe. After all, you are giving mutable access to a "field" of the world while sill providing &mut World. That is inherently unsafe, even if you add a ton of guardrails. That said, I think we should look into alternatives to the scope pattern here. I think improving the run_system_once + Commands is probably a better way to handle these situations IMO. And in the rare case that the "remove, scope, and re-add" workflow is needed, I'd almost rather it be explicit, so users can see all the risks and side-effects openly. But that's just my opinion, and (for good reason) this is not my decision to make.

I'll try to find time to review the code later if possible. This is a really good idea to explore, but it is very complicated.