For the sake of performance, I didn't reuse the LoadBalancer and LoadBalancerContext.

this feels like a setup for future sadness, how bad was the perf hit that made this the preferable choice?

At the very least, I'd say move everything that is common to both into their own functions so the logic will be consistent across them both. this will also make it easier to see the ways in which these differ, like I can tell they are sliiightly different but its hard to determine where without also pulling up the other code, if all common logic is in the same spot it'll be clear what the differences are.

this feels like a setup for future sadness, how bad was the perf hit that made this the preferable choice?

This function is I/O bound:

For rescheduling, the today is the last review date, so I have to re-create load balancer for each card. It's very slow. It would take 1 minute to reschedule thousands of cards.

For future maintenance, we definitely want as much code shared between the paths as possible - whether that's by reusing old code and doing things like mutating an existing context for each card instead of creating a new one (which may not be practical here), or by introducing this new code and having the old code use it.

Does this change respect the mw.col.load_balancer_enabled option?

Does this change respect the mw.col.load_balancer_enabled option?

It does now.

For future maintenance, we definitely want as much code shared between the paths as possible - whether that's by reusing old code and doing things like mutating an existing context for each card instead of creating a new one (which may not be practical here), or by introducing this new code and having the old code use it.

I'm reusing some code snippet now.

In the latest commit, if the user changes the easy days setting and enable "reschedule cards on change", the rescheduling will be executed without modifying the desired retention or FSRS parameters.

Thanks Jarrett, this should make a lot of people happy. As this is largely based on @jakeprobst's code, I'll defer to him on the final approval, but no issues from my end.

One thought: it won't be obvious to users that reschedule on change affects easy days as it's in a different section. One optional improvement would be to display a yellow warning when easy days are changed and reschedule is off - something like:

"Existing reviews will not be rescheduled unless '{ deck-config-reschedule-cards-on-change }' is enabled in the FSRS options."

looks good to me!

In the 51f43f5, I added this warning:

It works well with previous warning, too.

Existing reviews will not be rescheduled unless 'Reschedule cards on change' is enabled in the FSRS options.

What if the user doesn't have FSRS enabled? IMO, this warning should be hidden in that case.

Also somewhat related:
Currently, the FSRS helper add-on has its own implementation of load balancer and easy days. Does it make sense to expose the Rust code to add-ons so that the Helper add-on could use it directly instead of re-implementing it in Python?

Currently, the FSRS helper add-on has its own implementation of load balancer and easy days. Does it make sense to expose the Rust code to add-ons so that the Helper add-on could use it directly instead of re-implementing it in Python?

My initial thought is this is probably really difficult to do, unfortunately

What if the user doesn't have FSRS enabled? IMO, this warning should be hidden in that case.

I thought about it, but hiding it gives the user no clue that it's not retroactive in the SM2 case.

Thanks everyone!

Sorry, I try to remove my attribution when making such trivial changes, but I forgot again. :-(