Alternate reversable fixed-timestep Schedule and `Time` instance about bevy

[CHATALOT1]

I have thought of a much simpler solution that should meet my game's use case, at least. I am curious as to the efficiency differences between the two ideas, if any. Instead of creating two schedules and adding a version of the system to each, I have created a set of States:

/// Whether time is currently flowing, and its direction if so.
#[derive(States, Default, Debug, Clone, Copy, PartialEq, Eq, Hash)]
enum TimeFlowState {
    #[default]
    Paused,
    Advancing,
    Reversing,
}

An app extension then provides a convenience method that allows one to add systems that do and undo the desired reversable functionality:

impl ReversableTimeAppExt for App {
    /// Convenience method similar to `App::add_systems`, but automatically confines the provided
    /// `advancing_systems` to run only when in State `TimeFlowState::Advancing`, and the
    /// `reversing_systems` to run only when in State `TimeFlowState::Reversing`.
    ///
    /// It is assumed, although not enforced, that the systems passed as `reversing_systems` do the
    /// reverse of the systems passed as `advancing_systems`.
    fn add_reversable_systems<M>(
        &mut self,
        schedule: impl ScheduleLabel + Clone,
        advancing_systems: impl IntoSystemConfigs<M>,
        reversing_systems: impl IntoSystemConfigs<M>,
    ) -> &mut Self {
        self.add_systems(
            schedule.clone(),
            advancing_systems.run_if(in_state(TimeFlowState::Advancing)),
        )
        .add_systems(
            schedule,
            reversing_systems.run_if(in_state(TimeFlowState::Reversing)),
        )
    }
}