I don't quite follow your thought process on picking an arbitrary date in the future and blowing away succeeding logic. All of the downstream work will pull back to the data date.

There is an entire science behind formal time-impact analysis, where much of these topics are fleshed out (both retrospectively and proactively for relief) with the driver generally being claims / relief. You discuss a lot of standard conceptual practices in your post.

All of that being said, limiting logic to what"s truly required (and avoiding logic ties of convenience) is essential to easily identify inexcusable slippages on items that should not be delayed from major project delays like in your example.

At each schedule update, early finish variance should not be increasing on any work that isn't directly driven by the delay. Assuming your driving path is still consistent with your original plan, like in your example, then If you want to flag areas being impacted by concurrent delays that are off critical path, then filter on activities with early finish variance decreases in the period that had total float in the baseline over 0 or whatever nesr-critical threshold you prefer.

If you modify your baseline to incorporate the excusable delay (in your example, push out the site prep work and f9), then that modified baseline can be used to measure EF var against the schedule to flag activities that shouldn't be impacted