Will clarify as follows If the data element being referenced has targetProfile resources, only those targetProfile resources that have URLs that exist in the referencing version can exist.  If a resource has been renamed, it can't be used in the prior release.  This is because there's no computable way of determining what names would be allowed.  We will define new 'standard' extensions with contexts of Reference and canonical respectively called "alternateReference" and "alternateCanonical" that allows pointing to any resource.  E.g. if converting from a version that supports 3 target types when the target version only supports 2 target types, any repetition that referred to the non-supported type would be represented as a reference or canonical instance where the content would just be the alternate extension. We will expand on the section talking about representing complex types using extensions by saying the following:  The overall extension will contain child extensions, one for each property of the complex type being converted.  If necessary, this will occur for child elements too.  I.e. if a complex type has a complex child, there will be an extension containing child extensions.   We will provide an example showing what this will look like When converting a data type to a target version where that type doesn't exist (meaning it's either a simple type that will use the mapping table or a complex type that will be converted to a set of child extensions), if the converted element is a choice, there will be a child extension added to the element (an extension on the target simple type or an additional sibling to the child extensions for a complex type)with the name "_datatype" that will contain the name of the complex type in the source version. Will make clear that extensions should absolutely propagate.  Will submit a Git issue asking for a flag to be added to the validator that says "acceptUnknownHL7Extensions" that will handle the special case of the stricter validation that we apply to HL7-defined extensions that would choke at seeing extensions from an unrecognized version.  This same extension should also make extension validation more lenient - i.e. don't presume that the definition available in the current version for the HL7 extension is the right one and treat validation errors against a defined extension or missing extension as warnings rather than errors. The extension mechanism will carry no information about cardinalities.  If converting from the extension mechanism to 'core' elements when up-converting or down-converting the resource, the conversion process will need to know the max occurs for the element in the target version to know whether the element should be a JSON array or not. We will create the actual packages so that the links resolve.  (And as part of that creation process, see if there are any other fun gotchas we haven't caught here yet :>)