A-Frame Hot-Reload Component Reinitialization Order Lacks a Documented Configuration

A-Frame's hot-reload workflow, commonly provided by plugins such as aframe-hot-reload, re-instantiates a component when its source changes instead of reloading the whole page. The goal is a repeatable development environment: a scene should reach the same state after a hot reload as it does after a full refresh.

The missing constraint is ordering. A-Frame does not document a configurable reinitialization order for hot reloads. In a scene where one component reads state that a sibling component sets during its own init, the reading component can run before the provider has been re-instantiated, and the resulting order may differ between reloads. Guard flags and deferred reads in tick are developer conventions, not framework-enforced guarantees.

Is there a documented setting or lifecycle hook that makes component reinitialization order deterministic during hot reload? Should dependent reads be moved out of init into update or tick so ordering no longer matters? Is a full page refresh currently the only reliable way to reproduce production-like initialization order?