Query caching in Bevy 0.15: stale component views after Commands

Problem

In Bevy 0.15, a system that adds a component to an entity via Commands and then immediately queries for that component within the same frame often receives an empty or stale result set. This occurs because the world rebuilds archetype caches only when the archetype table list changes, and structural changes applied by Commands are flushed only at the end of the frame in apply_deferred.

Goal

Determine whether this delayed cache update is an intentional design choice, how it is documented, and what options exist to work around or configure the behavior for scenarios that require immediate visibility of newly added components.

Constraints & Uncertainty

• The issue appears only when component additions happen via Commands and a query is performed in the same system or stage.
• Bevy’s documentation mentions deferred application for parallelism but does not explicitly state the cache rebuild timing.
• Potential workarounds (splitting logic across frames, using Local, or calling world.flush()) can affect performance or safety.

Questions

1. Is the observed stale cache behavior in Bevy 0.15 intentional and documented, or is it a known bug that will be addressed in a future release?
2. What are the officially recommended patterns for accessing components that were added via Commands within the same frame?
3. Does Bevy expose any scheduler or configuration flags that can alter the deferred command application boundary to allow immediate query visibility?