Sarwan
Ideally from a security standpoint, we would like to have the strongest applied based off the Journey. In the example that was showcased, It'd be [2] - if the journey being performed is, User entering wrong password three times.
From a product standpoint, we'd like the product to function as per the strongest being enforced. I'd test this as the configuration is not complex. Also the smtracedefault.log spews out the password policy actions which would help us validate our thought.
Having said the above, Here another purview (Just me 1 cent)....
From an Organizational Security perspective what is the password policy we would like to be enforced. Having two password policy for the same subset of users seems like a detrimental design / implementation. It really doesn't make sense, for e.g. Single Identity Store, Single User, Two or more Password Policy applied - why? It would be an absolute nightmare to manage password resets and user experience behaviour; if this were to continue.
I'd ideally look at designing a password policy for which is nuclear to a set of users. A good design of password policy should never be in this situation where the same subset of users are actionable across different password policies.
Regards
Hubert