Clarification for hierachical properties needed

Summary from discusion on the mailing list:
Property definitions can be a) hierachical and b) multi-value
We need to clarify how a repository should/can behave here and what the intended use case is:

One possible interpretation:
the spec says for choice lists (1.0D4, 2.1.3.3.2):
"Choices: Indicates an explicit ordered set of values allowed for this property."

Possible interpretation A:
For multi valued properties each choice is designed to be again a list of values. Let's say I have a string property definition ColorModel of cardinality MULTI with two choices
Choice[0] =

Choice[1] =

Possible Interpretation B:
Choice lists can be hierarchical such as (Country) -> (State/Region) -> City and mostly used with single value properties (e.g., only one item selected). If used with multi-valued properties, then multiple single elements can be chosen.

A bigger issue is that there seem to be two ways to specify choices for a multi-valued property.
[Jen's model] A multi-value is considered a single list-value. An application must make a single choice among several allowable list-values.
[Al's model] A multi-value is considered a list of single values. An application is expected to make multiple selections from a set of allowable single values.
The two models are not the same. Shall we support both? If both are supported by the spec, a choices specification then must syntactically distinguish between a single value and a list value, and must not allow a mixture of both in choices. However, a repository implementation can restrict a choices specification to one of the two forms since type definition is outside CMIS.

Suggest to make B the recommended way (SHOULD?) and others optional (MAY)
Suggest to add an XML dump for B as example to our spec