A replay frame processed in CatchInputManager is applied to catcher in `CatcherArea`.
The catcher position is then used for the catching logic for each hit object under `HitObjectContainer`.
Thus, if `HitObjectContainer` came before `CatcherArea`, the replay input is delayed one frame.
That was one reason why the catch autoplay misses hit objects (especially when fast-forwarded).
While it is the case for the existing official Skills, Skill implementations shouldn't be required to conform to a strain based approach.
There are other valid approaches to calculating skill difficulty that can be supported by abstracting the strain logic into its own StrainSkill class.
As strains are an implementation detail of the current Skill calculations, it makes sense that strain related logic should be encapsulated within the Skill class.
In catch, rate adjustment mods do not only affect the timings of hitobjects, but also the speed of the player's catcher.
This catcher speed change has an impact on difficulty which is currently accounted for by using the clockrate directly in calculations.
Semantically this is a bad idea because clockrate adjustments are supposed to be fully accounted for in DifficultyHitObjects, but passing clockrate here for the purpose of being used as catcher speed doesn't make much sense, especially since it is copied in every DifficultyHitObject despite being the same value.
It makes more sense to account for this catch specific impact by handling rate adjustment mods in a catch specific way, or more specifically in a Movement skill specific way.
Although this isn't necessary for existing official rulesets and calculators, custom calculators can have use cases for accessing mods in difficulty calculation.
For example, accounting for the effects of visual mods.
