At my job, in our core project, we have a Validation class that has been evolving with the years. And ee have an old project with an User class that uses an old version of the Valdiation class.
And we have to update some functionality that requires new validation methods. All those methods are implemented in our latest Validation class.
But the new Validation class isn't backwards compatible, so we can't just put the new one in place.
I thought that a good solution would be to upgrade all the code that references the Validation Class or making it backwards compatible but, obviously, both of them would take a lot of time.
Finally, it was decided that adding the latest version and calling it Validation2 works just fine, some methods use Valdiation and others Validation2. I think that will bring a lot of problems later, because you don't know when to use one or another as the names stop being meaningful.
What could be a better option to deal with this?
Also, the Validation class was the best example, but we have the same problem with a lot of bigger and more complicated classes and now we have a lot of "duplicated" classes. The language is PHP, but could happen in other languages too.
If the classes represent different concepts (in this case they are different agents that perform different tasks), they must have different names.
In your place I would give them different names that represent particularities of their natures. Not only a version number, but a meaningful name (you already pointed out why).
Besides, I would create a superclass and make this two validators to descend from it, a validator taxonomy comes to exist.
As time passes, I would work to replace the old validators by the new ones until the old one becomes unused, then I would remove it from the code.