UMLR — Why is a qualified association qualifier composed by a Property?

Consider the example in Fig 11.37 that is supported by the OCL navigation aBank.Person[accountNo].

The nested Property is novel but avoids any bias as to whether the keys are actually part of e.g. a HashMap in Bank, or a linear search in Person. Seems good, but...

How does aPerson discover their accountNo? Oops need to do a total content search of the Bank. Or provide duplicate Person::accountNo state with all the hazards that duplicate state entails.

How can two qualified associations share the same qualifier? Can't it's Composed. Need yet more state duplication.

If instead, Property::qualifier was not Composed, many qualified associations can refer to a Property that can be a regular unnested Property that can be navigated as aPerson.accountNo. Although the now regular Property appears hosted by the target, there is no prohibition on an implementation using a HashMap and locating it in the source, iff all required forms of access are supported.