When a schema <include>s a namespace through the <references> element, it can optionally assign an alias to that namespace. Elements defined within the included namespace can be referenced qualified with the full namespace name or the alias name, if provided.
We have rules that the alias, if used, must be unique within the schema, and that the same namespace cannot be included more than once.
In most cases we expect shared namespaces to be disambiguated through a multi-part name, such as "Org.OData.V1", but we don't require namespaces to contain a period, and non-shared namespaces are likely to be a simple identifier.
We don't currently say what happens if an alias is introduced that matches the name of an included namespace. Does the alias take precedence, or does the namespace take precedence, or is this a schema validation error.
Since the schema designer has control over the alias name, and not the namespace they are importing, an argument could be made for saying that the alias takes precedence over the namespace.
We should think through what happens if a schema includes a namespace and uses a type that has a property whose type is defined in a third (non-included) namespace that conflicts with an included namespace or alias. Right now I think we say that the namespace of the namespace containing the type of the property must also be included, but I don't know how practical that is in all cases.
To be backward compatible we should probably say that services SHOULD NOT use aliases that conflict with included namespaces, and that clients SHOULD assume that, in such cases, the alias takes precedence.