Did you have any sort of testing or simulation procedure for this?

nope, it's just yolo. in my attempts to reproduce the user failure (caused by a pc stutter) i could not. you can try adding a Thread.Sleep to be scheduled in Player:

diff --git a/osu.Game/Screens/Play/Player.cs b/osu.Game/Screens/Play/Player.cs
index 21e0d3c8b9..f6e4d30f91 100644
--- a/osu.Game/Screens/Play/Player.cs
+++ b/osu.Game/Screens/Play/Player.cs
@@ -213,6 +213,8 @@ protected override void LoadComplete()
             ScoreProcessor.OnResetFromReplayFrame += () => ScoreProcessor.PopulateScore(Score.ScoreInfo);
 
             gameActive.BindValueChanged(_ => updatePauseOnFocusLostState(), true);
+
+            Scheduler.AddDelayed(() => Thread.Sleep(1500), 5000);
         }
 
         /// <summary>

But I couldn't get this to trigger the permanent failure scenario.

you can try adding a Thread.Sleep to be scheduled in Player:

I don't think this does anything to help test this. Yes it incurs a freeze, but that's immaterial, because none of the logic touched here runs in that scenario. Which is logical, since a sleep inside a schedule incurs a full update thread block during which FrameStabilityContainer will not run.

I dunno, all I can offer at this point is a yolo approve. I am reading the fourth? iteration of this bass hack and I am at a total loss as to what it's going to do or not do.

Actually, slight correction to the above, I think there's a chance that this PR isn't going to help in the full freeze scenario.

If the user is full-frozen on the bass hack, then that means this condition will be true for them every frame (taken from master):

This PR tries to only block for 3 frames at a time instead, via

and if 3 frames are exceeded then the logic is allowed to continue. Unfortunately invalidBassTimeLogCount is zeroed immediately after this:

so the block will probably trigger again.

I came to this conclusion via the extremely stupid diff of

diff --git a/osu.Game/Rulesets/UI/FrameStabilityContainer.cs b/osu.Game/Rulesets/UI/FrameStabilityContainer.cs
index e727fb48fe..01d48548e4 100644
--- a/osu.Game/Rulesets/UI/FrameStabilityContainer.cs
+++ b/osu.Game/Rulesets/UI/FrameStabilityContainer.cs
@@ -161,7 +161,7 @@ private void updateClock()
             //
             // In testing this triggers *very* rarely even when set to super low values (10 ms). The cases we're worried about involve multi-second jumps.
             // A difference of more than 500 ms seems like a sane number we should never exceed.
-            if (!allowReferenceClockSeeks && Math.Abs(proposedTime - referenceClock.CurrentTime) > 500)
+            if (referenceClock.CurrentTime >= 500)
             {
                 const int max_frames_to_ignore = 3;
 

which not only makes the conditional trigger constantly after time 500 instead of once, but also makes the drift between reference clock and proposed time bigger?

You have very valid concerns here. The logic in this method is beyond me, so I'll do another pass and probably refactor things to actually make sense before attempting this again...