Typically in OPC UA versioning is done through the NamespaceMetadataType (See OPC UA Part 5). However, in the Semantic Web the version number can also be reflected in the NamespaceURI, for example:
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix grddl: <http://www.w3.org/2003/g/data-view#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

Based on that, the OPC UA NamespaceUri can be used in a similar way. For example, the following NamespaceUris and the corresponding PublicationDates:

<NamespaceUris>
    <Uri>http://opcfoundation.org/UA/CNC</Uri>
    <Uri>http://myDemoServer.org/</Uri>
</NamespaceUris>
<Models>
    <Model ModelUri="http://opcfoundation.org/UA/CNC" PublicationDate="2018-06-01T00:00:00Z" Version="1.00">
        <RequiredModel ModelUri="http://opcfoundation.org/UA/" PublicationDate="2013-12-02T00:00:00Z" Version="1.03"/>
    </Model>
    <Model ModelUri="http://myDemoServer.org/" PublicationDate="2018-06-01T00:00:00Z" Version="1.00">
        <RequiredModel ModelUri="http://opcfoundation.org/UA/" PublicationDate="2013-12-02T00:00:00Z" Version="1.03"/>
        <RequiredModel ModelUri="http://opcfoundation.org/UA/CNC" PublicationDate="2018-06-01T00:00:00Z" Version="1.00"/>
    </Model>
</Models>

Shall be expressed as (format: yyyy-mm-dd based on PublicationDate):
http://opcfoundation.org/UA/CNC/2018-06-01/
http://opcfoundation.org/UA/2013-12-02/

While the Standard NamespaceUris:
http://opcfoundation.org/UA/CNC/
http://opcfoundation.org/UA/
Always stand for the latest version of the given Namespace.

This can also be used to solve the OPC UA Aggregating Server issue, which is related to this topic.
It is theoretically possible to introduce two identical NamespaceUris with different versions and therefore generate two entries in the NamespaceArray and two NamespaceMetadataTypes. However, there are various dependencies troughout the specification (besides possible implementation problems), which do not permit to introduce two identical NamespaceUris, because the corresponding version cannot be expressed, for example:
• Part 4 7.29 ResponseHeader: The stringTable of the ResponseHeader: “There is one string in this list for each unique namespace,…”
• Part 4 7.11 ExpandedNodeId: namespaceUri “The URI of the namespace. If this parameter is specified then the namespace index is ignored. 5.4 and Part 12 describes discovery mechanism that can be used to resolve URIs into URLs.”
• Part 4 6.3.2 SessionlessInvoke: namespaceUris [] “A list of URIs referenced by NodeIds or QualifiedNames in the request. NamespaceIndex 0 shall not be in this list. The first entry in this list is NamespaceIndex 1. The parameter shall be ignored by the Server if the urisVersion is not 0.”
• Part 4 7.25 ReferenceDescription: nodeId “If the serverIndex indicates that the TargetNode is a remote Node, then the nodeId shall contain the absolute namespace URI. If the TargetNode is a local Node the nodeId shall contain the namespace index.”
• …

In future automation setups it is highly possible that an aggregating server (edge / cloud) has to expose Companion Specifications of different versions, which will become a serious problem...
An overall solution / guideline for versioning of OPC UA information models is necessary...

Some Companion Specifications already try to address this problem, but not all of them (NodeSet-Files):
<NamespaceUris>
<Uri>http://www.OPCFoundation.org/UA/2013/01/ISA95&lt;/Uri>
</NamespaceUris>
<NamespaceUris>
<Uri>http://opcfoundation.org/UA/MTConnect/&lt;/Uri>
</NamespaceUris>
<NamespaceUris>
<Uri>http://opcfoundation.org/UA/ADI/&lt;/Uri>
<Uri>http://opcfoundation.org/UA/DI/&lt;/Uri>
</NamespaceUris>