The prohibition of numeric indices is not due to best practice, but is a requirement of FSH and FHIR. Constraints on repeating elements in FHIR apply to each repetition , so you cannot directly fix an array to a list of values; you must do this through slicing. As such, using numeric indices cannot work here like it does in Instances. It is possible to fix an element to a complex value, and for that value to have an ordered array at a child element path – but this is not directly supported in FSH syntax except through caret rules or by assigning an Instance as the value. The exception for caret rules is already noted in the spec, and assignment by instance is irrelevant to the discussion since the numeric index would be in the Instance, not the Profile. When exploring approaches to implementing ordered arrays in profiles using slicing, the commenter noted (on Zulip) that R5 profiles may use the `position` discriminator type. This discriminator relies on the order in which slices are defined in the profile. As such, the FSH specification should be updated to reflect the order in which slices will be created in the profile. We propose updating 3.6.7 Contains Rules for Slicing to include text similar to the following (likely in step 2): Implementers MUST add new slices to the profile in the order in which they appear within the contains rule. When a profile definition has multiple contains rules on the same path, these rules MUST be processed in the order in which they appear in the definition.