Reference modes provide a shorthand notation for an extremely common pattern. With a shorthand notation not all of the information is displayed on the diagram. This is no different from the Visio solution and other solutions where some of the reference mode details (separator, etc) are not clearly displayed on the diagram. Similarly, ORM diagrams don't display datatypes. In any case, you will not see the readings for the underlying existential FactType when you collapse reference modes. There are also voices asking for customization of the default set of reference modes (generally to reduce that set, although extension also applies), which is at odds with your desire to have the shorthand notation match exactly the same pattern on all models. Your restrictive request followed to its logical conclusion also means that there are no custom reference modes because these would be non-standard, and hence the shorthand could not convey the full meaning. Certainly, we could allow a synchronization command between the current machine settings and those in a given model, but I believe that attempting to do this automatically and dynamically changing meanings in a stable model based on environmental changes is fundamentally a bad idea. Stability of individual models clearly trumps the need for updates.
Cross-model references are a different topic, and an area we will address after the single-model mappings are handled cleanly. Cross model synchronization is also a major issue (what happens when your external model changes?). Certainly, if you want to have a set of RMPs defined in an external model you can do this and have no defaults. However, I think having a populated (yet configurable) set of common RMPs available for a new model is also important. I don't think one world view (fixed set of reference modes only) needs to lock out the other possibilities, and you can certainly configure the tool anyway you like by removing all the default RMPs, adding them to a starting template, etc.
Unit and Popular are fundamentally different notions. Multiple entity types may bind to the same ValueType and match the same RMP. The same is not true for a Popular reference mode.
hectare is an area (length*length), not the other way around, so hectare is definable in terms of two length units and a conversion factor. This will give you a unit, but not a ValueType. The ValueType itself has additional datatype and conceptual information not available directly from a unit. We haven't formally modeled this yet and locked down underlying names, but I would consider {length,area,mass,etc} to be fundamental units, whereas {m,cm,mm,in,acre,hectare,kg,lb,etc} to be standard units that correspond to fundamental units. Formalizing the notion of unit provides a clean conversion mechanism. So, for example, conversion factors can be applied automatically to a derived BMI value (unit is m*m/kg) can be calculated seamlessly even if weight is recorded in pounds and height in inches. In any case, unless I'm badly misreading your syntax, Area(10000*m*m:hectare) looks like its backwards (a fundamental unit defined in terms of a standard unit).
Whether an Id is sortable or not is more of a function of the data type, which is independent of the matched RMP. I'm not sure its a question we need to consider, though. If Id matches a popular RMP, then the lexical values have no meaning outside the set of identifiers for the population of a given entitytype (and its subtypes). Clearly, for unit-based values, comparison/conversion is conceptually meaningful, but not for popular reference modes.
-Matt
PS I'm following this thread where it was started. I don't object to following the yahoo list as well, which is housing most of the recent traffic.