It's a mere convention: "a querystring of this type is an array of parameters, the order of which is irrelevant" - this is one of the tautological "valid except when it's not" non-rules (a surprising number of cases).
Example: ?a=1&b=2&a=3 - will the server treat this to be equivalent as ?a=3&b=2&a=1 , or ?b=2&a=1 , ?b=2&a=3 , or something else entirely? You'd need to check the serverside parsing implementation to be sure - those could even be valid (and distinct) filenames FWIW.
(And that's before you get to caching - "?b=2&a=1 is not to be served as a cached version of ?a=1&b=2")
The repeated case is something I hadn't thought of when I wrote the original comment since I would never do that so this got me curious. Looks like it _isn't_ guaranteed by any spec, and different frameworks have their own rules as you pointed out. For example, PHP will take the last duplicate param value as the "winner", and others group them into an array.
While I think this would be a bad application design, it looks like swapping the order of params could result in errors in some cases. In practice though I would treat the URLs the same.
You would never do that, I wouldn't either, but in machine-to-machine API interactions, this tends to crop up - i.e. a SW stack where this implies "an array of `a` values and a scalar `b` value" sends the data to a SW stack where "last `a` wins, last `b` wins", and strange bugs ensue, as both sides insist they're doing The Right Thing :)
Example: ?a=1&b=2&a=3 - will the server treat this to be equivalent as ?a=3&b=2&a=1 , or ?b=2&a=1 , ?b=2&a=3 , or something else entirely? You'd need to check the serverside parsing implementation to be sure - those could even be valid (and distinct) filenames FWIW.
(And that's before you get to caching - "?b=2&a=1 is not to be served as a cached version of ?a=1&b=2")