Presumably you would apply the same sanitizer at login time to whatever password the user enters. If the input is the same and the transform is the same then the output will be the same.

Hopefully you don't actually have to do any of this because your backend wasn't written by monkeys on typewriters.

What may happen is that every step is siloed in some way and every team assume the others are monkeys on typewriters. From a security perspective, it is not necessarily a bad thing, but it can make the user experience terrible.

For example, I may write some piece of software that refuses to write files with spaces in them, because I suspect that later on, some shell script will process them and it is very common for poorly written shell script to break with spaces in file names. But it may turn out that unexpectedly, the people who write the back end are competent and deal with spaces just fine. But on their side they may expect me to be be the monkey and say, avoid replying with Unicode characters, assuming my code will break if it gets something that is not an ASCII printable character.

So in the end, the user will have neither spaces in file names nor proper Unicode support, even though the software wouldn't have any problem with that if two team properly communicated and didn't think of each others as monkeys.

This relies on a false assumption that the sanitizer is static.

If we're to continue with this thought experiment in doing the dumb thing. Clearly you would version your sanitizer and store which version you used when saving the password. That way you can ensure the same version is used against future user inputs.