Normalizers are attached to MatchingRules. An AttributeType might have up to three MR (EQUALITY, ORDERING and SUBSTR). Normalization is always done using the EQUALITY MR, regardless the MR used.
This has an impact on the DN normalization, and AT normalization that is done very early in the requests processing. We also stores a normalized form of each DN withing the LdapDN data structure, to avoid a costly operation to take place when searching for a value.
This is a good thing as far as the potential MR a AT can use are all using the same Normalizer, but the first time we will have a MR using a different normalizer, the search will fail.
Right now, I suggest we keep doing what we are doing, ie, using the EQUALITY MR as a default. It's very unlikely that it will have an impact on the server.
As a side note, one can wonder when do we have a different normalizer used for an AT, and there is a clear use case : when using a approx filter, for instance, or a substr filter, normalization can be different(we may use a phonetic normalization for the approx filter, and the normalization can be different if we are using a SUBSTR MR too). So far, we are ok as we don't support the approx filter...