Its super fast & easy to take a business service like CustomerLoginService and copypasta it into a new version called CustomerLoginService2 which addresses 99% of the same stuff but has a small tweaks throughout to help with some special business edge case or migration to a new way of doing things. Adding the new service to DI and being able to access it (in a well-designed application) is typically 1 line of code on both counts.
I don't worry too much about this kind of stuff anymore. If we end up with 5+ copies of this thing and it actually causes problems or otherwise slows us down, then I would probably consider taking the time to actually clean it up using something like parameters, inheritance, or generics to establish desired context of usage and normalize code.
This sort of scheme might look tacky and trigger developers a little bit, but seeing CustomerLoginService2 in a stack trace and being able to instantly zoom to a scoped implementation unique for that context of usage is a pretty big advantage. Contrast with if you were to normalize down to a single CustomerLoginService. Debugging the added conditionals & state will certainly be more cumbersome.