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.
There is no reason we should be limiting skills to knowing only the previous 2 objects. This originally existed as an angle implementation detail of the original pp+ codebase which made its way here, but didn't get used in the same 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.
When starting a new section, the starting strain value was calculated using the unadjusted timing value, meaning decay curves were essentially being stretched or squashed according to the clockrate.
This caused incorrect strain peaks for any section where the peak occurs at the start of the section (none of the objects in the section added enough strain after decay to exceed the starting strain).
This bug caused star ratings with clockrates above 1 to be lower than they should and below 1 to be higher than they should.
