We can consider completely removing this parameter for newer clients

I also thought about that, but I was strictly following this requirement: https://linear.app/comm/issue/ENG-2541#comment-a48dff3b. It explicitly advices to keep it as optional parameter even though we should ignore it altogether.

Hmm... I think @tomek is referring to the client side, not the keyserver side. He's saying we shouldn't pass that data up from newer clients, right?

My idea here was to have two different validators, one with and one without password, and choose them based on viewer's code version.

What is the benefit of this approach? Moreover the choice between validators based on code version, should still be restricted to non-SIWE accounts (SWIE accounts shouldn't have to provide password regardless of code version). As far as I can see this approach introduces noticeable complexity, but I can't see benefits.
Additionally, I am really sorry for not starting this discussion before landing this differential - I was in a rush to land this stack to meet the deadline, but still should have at least share my opinion before landing.

Overall we should be precise about declaring our API. In theory we could declare the requests to be inexact, accept any object, and take from it whatever interests us and ignore anything else. But that will degrade maintainability.

So the maintainability is probably the most important benefit here. If we declare that all the clients above some code version aren't supposed to send this parameter, we could ultimately delete it after bumping minimal supported version.

Also, when we are precise when declaring the API, we can safely implement it without guessing. In the future someone may start wondering why this is an optional prop and when clients send it. Some searching though blame will clarify the issue, but it is less convenient that stating it explicitly.

On the other hand having different validators for different code versions also complicates the code.

Also SIWE increases the complexity, so maybe it's better to not change this.