Write Barriers for ECS Data

[caniko]

Summary

A schedule-level primitive that locks writes to a chosen component type between a producer set and a consumer set, with a static check at schedule construction that no other system in the window mutates it. Resources are covered by the same API because as of 0.19 they are components on singleton entities.

The motivation is a real production desync in a deterministic P2P multiplayer Bevy project: a phase hash is queued by an observer on BoardSeededEvent and flushed in PostUpdate; an unrelated auto-play system in the same schedule mutates RoundState between queue and flush; peers hash at different logical moments and the session enters infinite state-sync recovery.

.before(FlushPhaseHashSet) patches this specific writer. The next writer ships the bug again, because nothing tells a new contributor about the window. This RFC makes that schedule-build error instead of production-runtime corruption.

The RFC includes a worked end-to-end example (before/after code, schedule-build diagnostic, fix line) drawn from the motivating bug.

Scope

• v1: single schedule
• Cross-schedule and cross-subapp barriers deferred to Future possibilities
• Command-mediated writes via a per-system write manifest (.may_insert::<T>()), strict by default with a lax mode for prototyping
• Built on the 0.19 substrate: resources-as-components (#20934), expanded FilteredAccess (#23384), SystemBuffer::queue() (#22832), delayed commands (#23090)

Related Bevy work acknowledged in the RFC

Open RFCs: #16 Subworld, #36 Side Effect Lifecycles, #46 Atomic schedule groups (closest sibling), #47 Relaxed ordering.
Shipped in 0.19: #20934 + chain, #22144, #22602, #23090, #23384, #23414, #22832.
Outstanding issues: #4918, #15036, #14951, #18310, #23057.

Open questions called out

• Final API name (WriteBarrier collides with informal community usage for command-queue sync points)
• Strict vs lax default for command-mediated writes
• Result-returning vs panic-on-violation at schedule build

Feedback particularly welcome on those three and on whether the diagnostic shape in Implementation strategy matches what #15036 will land on.