Allow to always apply the calculated beatmap offset. (The idea is quite fleshed out and rigorous. Doing this without any logic would be a disaster and I am aware of that)

[Inconsist]

For those who might read this and don't know, I am talking about improving this feature right here which can be seen every time you restart a map:

General idea & why it works:

After every finished or restarted play, the game already calculates a suggested offset for you. My idea is to have the option, to always apply this offset after every play/restart of a map.

Intuitively it makes sense that if you continuously apply the calculated offset after each run, you would eventually stabilize in an area, maybe go from

1 run: -15ms
2 run: +3ms
3 run: -2ms
4 run: +1ms
5 run: -0.5ms

Theoretically these values should stabilize at some point with minor run to run variance. These also get more certain the more you have played the map. Maybe on the first play you were not yet used to the rhythm, but all of these things approach their optimum values as you play the map more and more.

Valid Concerns :"But what about plays like these"

this run had a sample size of 51 and a ur of about 540. Obviously no offset should be applied here right?

How to make it relaiable and make the right decisions on edge cases of low sample size & high UR

A more robust approach would be to make the applied offset proportional to how low the ur of the play was. So change always happens regardless of the sample size, the change is just very small when the ur is a terribly high value.
This would be a good way to make the feature never make wildly wrong decisions if the play doesnt allow for the certainty that we can make that change.

The Math

This would be my suggested implementation where x is the UR of the play and the result between [0,1] is multiplied with the calculated offset.
Of course the exponent can be finetuned further, if necessary, but this value feels like a good starting point in my opinion
(the limitations in this case are just for the visual representation. Obvisoulsy UR is never negative and the UR<100? can be done with an if statement. But this graph shows my idea in a more understanable way)

Examples

example worst case:

540 ur on the play
suggested change to offset is +30.1ms
ur -> x in the function returns 0.0368
30.1ms * 0.0368 = 1.84ms
so the offset would actually only be adjusted for +1.84ms because the play is very meaningless with regard to our confidence in the correctness of the change.

example ordinary case:

135 ur on the play
suggested change to offset is +12.1ms
ur -> x in the function returns 0.7691
12.1 * 0.7691 = 9.3ms
so the offset would actually be adjusted for +9.3ms because the play is more meaningful

example best case:

92 UR on the play
-> we assume the player is correct and apply the offset calculated as is.

final thoughts

With all these precautions in place, I think this would be a great quality of life improvement, especially since with the current system you have to “catch” the button to calibrate, before it disappears, and you have to set another play to do it. This happens a lot when using "restart on fail" on SD or PF mod for example. Also since every setting is optional it could be turned off by default and would not disturb or confuse new players.
If there are any oversights on my part I am eager to discuss them and how to improve this further.

[peppy]

Maybe there could be an option, but it would definitely not be the default. Clicking the button on retry is easy enough.

[Inconsist]

Yes certainly not as a default. But I must disagree, when playing with a tablet and when using auto restart on mods, I have missed this so many times because it disappears too fast, and I have to switch to mouse to click it. The experience that clicking it on retry is too hard is what got me started on the entire idea.

[Inconsist]

I mean at least for me the window literally disappears after a second or so even if I hover over it with the mouse pointer