`App::configure_sets` should work the same way as `.before` and `.after` about bevy

[hymm]

If I recall correctly, @maniwani was originally opposed to being allowed to configure system-type sets due to... concerns around being deliberate about public surface area for configuration?

Yeah. Like if you do my_system.after(apply_buffers) that's almost certainly not what you actually want. I think this is less of a concern now that apply_buffers is less necessary. The other internal system that I can think of that gets added to a schedule multiple times is transform propagation. In that case users will probably adding their own set to order against since there are 2 systems responsible for propagating transforms.

[maniwani]

If I recall correctly, @maniwani was originally opposed to being allowed to configure system-type sets due to... concerns around being deliberate about public surface area for configuration?

All instances of a given function will end up in the same SystemTypeSet, so if you have more than one instance of a system in the same schedule, configuring that set (or ordering on it) can be ambiguous in a very subtle way. If you add system foo and system bar where bar.after(foo), that's fine. But if you add another foo to that same schedule the bar.after(foo) constraint is implicitly applied to that one too.

IMO now that apply_deferred (the most at-risk system) is automated, if we discourage having many instances of the same system in the same schedule, then removing the limits on SystemTypeSet would be fine by me.

I think the problem would go away once all systems can be stored as entities, since there'd be no need to even have more than one instance of any system. Different schedules could grab the same instance (especially if we change the Box to an Arc).

[maniwani]

Also just want to mention that the schedule builder currently throws an error if you apply an ordering on system type sets that have multiple members (because of the ambiguity).

[alice-i-cecile]

Also just want to mention that the schedule builder currently throws an error if you apply an ordering on system type sets that have multiple members (because of the ambiguity).

Yep, I do like this safeguard, and think it should stay (at least for now). I think that with apply_deferred effectively no longer existing as a user-level concept + that safeguard we should be safe to relax the distinction and make configure_sets more consistent.