The choices for dealing with this inconsistency are: Leave as-is (pipe in Reference(This | That) and "or" elsewhere) Use pipe (|) everywhere Use "or" everywhere This comes down to a matter of taste. This issue was discussed with users on a FHIR Shorthand call (6/11), and #3 was the preference of most users. Therefore #3 is our proposed resolution. What follows are some notes regarding pros and cons of the three choices.  ---------- PROs for #1 (leaving as-is): 1) No non-compatible change introduced CONs for #1 : 1) Two ways to represent logical "or" 2) “Reference(This | That)” is a UI representation from the IG Publisher. The IG Publisher has frequently changed how it displays things, and Grahame could change it on any given day for any given reason. If he does, it will be a little harder to justify the use of “|” in References in FSH. --------- PROs for #2 (Pipe everywhere):   1) FSH tries to follow FHIR precedent when it can, which is why FSH uses the pipe inside References. In other contexts, there is no precedent. For maximum consistency, we would extend the FHIR precedent to other cases. Therefore, a rule like this:   * onset [x] only Age or AgeRange or DateRange would change to this:   * onset [x] only Age | AgeRange | DateRange which doesn't look bad. CONs for #2 1) It's a bit geeky 2) FSH uses the word 'and' in several different types of rules. If we use a logical symbol for "or", should FSH also use a logical symbol (&) for logical "and"? That would trigger a larger non-compatible change.  3) The pipe is also used to represent versioned code systems: system|version --------- PROs for #3 ("or" everywhere): 1) It's English, and FSH already uses "or" in other rules. 2) It's consistent with using "and" in other rules CONs for #3: 1) Inconsistent with the way FHIR currently represents Reference choices in IGs. However, this is a choice of the IG Publisher, not something intrinsic to FHIR. --------- The proposed resolution #3, allowing users a period of time to migrate when both | and "or" are accepted.