What problem does this solve or what need does it fill?

Currently, it is possible to ignore system order ambiguities for whole sets of systems by using the ambiguous_with API. However, it would be useful to ignore ambiguities resulting from specific components or resources to handle the situation where ambiguous uses of those types should not be considered a bug.

Motivation

In my app, many systems need write-only access to a specific component in order to send gameplay packets. The systems are ordered in such a way to ensure game logic correctness, but they're not ordered strictly enough to resolve the ambiguities. Resolving the ambiguities "properly" would pollute the schedule with ordering constraints between modules that do not actually depend on each other for correctness. This harms local reasoning.

What solution would you like?

Add ambiguous_resource and ambiguous_component methods to App and Schedule at least.

use bevy_ecs::{
    prelude::*,
    schedule::{LogLevel, ScheduleBuildSettings},
};

#[derive(Resource)]
struct MyResource;

fn main() {
    let mut world = World::new();
    world.insert_resource(MyResource);

    Schedule::default()
        .set_build_settings(ScheduleBuildSettings {
            ambiguity_detection: LogLevel::Error,
            ..Default::default()
        })
        .add_systems((foo, bar)) // Ambiguous systems.
        .ambiguous_resource::<MyResource>() // Mark the resource as ambiguous.
        .run(&mut world); // Does not panic.
}

fn foo(_: ResMut<MyResource>) {}

fn bar(_: ResMut<MyResource>) {}

What alternative(s) have you considered?

• Ignore the ambiguity detector entirely and wait for resolve conflicts by insertion order #9862.
• Do whatever flecs does in this situation. (Does flecs have ambiguity detection? Why or why not?)

Additional context

#8595 appears to solve a related but separate concern (that I would love to have a fix for!).