Recent versions of PHP, in particular since 8.1, are more particular about mixing static and non-static code. The error reported in #3317694: Error: Non-static method SmartDateRecurrenceFormatter::augmentOutput() cannot be called statically first seemed as though it could be fixed by making a single method static, but doing so would have required making a wide swath of Smart Date methods static, with no obvious indication that this is needed. On the contrary, there are numerous opinions around that using methods and properties statically should be avoided whenever possible.
Instead, the issue was addressed by moving more methods into the trait classes Smart Date uses to share common methods. SmartDateTrait was already made available as a service in #3331643: Deprecated: 'calling a static method on a trait, use class instead', but now the SmartDateRecurTrait is also available as a service. It's also worth noting that the SmartDateRecurTrait now also uses SmartDateTrait, so if your code requires methods from both, it can get all of them from the new smart_date_recur.manager service.
As a practical example, before this change it was possible to statically call some helper methods written for the SmartDateRule class:
$modal = SmartDateRule::getThirdPartyFallback($context, 'modal', 1);
Now, the same can be done using the new service:
$modal = \Drupal::service('smart_date_recur.manager')->getThirdPartyFallback($context, 'modal', 1);
Here is a summary of all the methods that can no longer be called statically:
SmartDateRule::getFrequencyLabels()
SmartDateRule::getFrequencyLabelsOrNull()
SmartDateRule::getMonthsLimit()
SmartDateRule::getThirdPartyFallback()
SmartDateRecurTrait::massageForOutput()
SmartDateRecurTrait::formatWithinDay()
SmartDateRecurTrait::addRangeClasses()
SmartDateRecurTrait::massageForOutput()
RecurFormatter::buildOutput()
RecurFormatter::findNextInstance()
RecurFormatter::findNextInstanceByDay()
RecurFormatter::loadSmartDateFormat()
RecurFormatter::subsetInstances()