/cc @wouterj As you added the class back then #40145 you maybe have use cases in mind where being able to extend this class is necessary. In that case we may have to figure out a different solution.

I believe there is a general policy to not make value objects final if they don't have an interface (or at least back then). Making this class final means your custom RememberMeHandlerInterface implementation cannot customize the value object (e.g. if it needs to store more data). Can't remember if I had a concrete use-case.

An alternative solution I have in mind is triggering a deprecation in case the custom implementation has its own constructor but does not also override the two static factory methods. Otherwise we risk that custom implementations break in 8.0 with our new constructor signature.

Although Wouter's rule make sense most of the times, I'm fine making this class final because I think the security-http API that exposes it doesn't make it a good extension point anyway.

An alternative solution I have in mind is triggering a deprecation in case the custom implementation has its own constructor but does not also override the two static factory methods. Otherwise we risk that custom implementations break in 8.0 with our new constructor signature.

OK, on closer inspection I understand the motivation - having the constructor part of a public API since we're calling new static().
What about triggering a deprecation from the factories when the constructor is overridden and has more than 2 required arguments?

What about triggering a deprecation from the factories when the constructor is overridden and has more than 2 required arguments?

works as well, I updated the PR accordingly

Thank you @xabbuh.