The order of variable is only referenced in section of the specification that are specific to PUBSub Configuration, so that item 1) & 2) are not issues. Our specification does mandate that both side match, but additional information should be provided for Items 3) and 4). More information maybe be required as part of a check (engineering units, datatypes) and then the confirmation via the pubsub message header information that the message is still of the version that was established may also be required.

ad 1 & 2) The issue is, that the dependency exists to the communication layer. Not a specific OPC UA communication model itself.
E.g.: Currently InputVariables and OutputVariables that are visible in the model of a FE, do not have any semantics of "order". It does not seem to be intuitive to introduce an order on how these variables are passed to EstablishConnections. We should avoid the FX abstraction to have dependencies on the communication layer in general.
ad 3 & 4) The current requirement on order of Variables only ensures that the PublishedDataSet on the Publisher contains the variables in the order passed to EstablishConnections. It does not ensure, that the Subscriber has the same understanding of order, or that its DataSetMetaData (which was created by the entity generating PubSubConfig) matches what was (pre-)configured on the Publisher.
This issue seems to be something that is supposed to be solved by Part 14 (most probably already part of the specification).

Order is also mentioned in 6.6.3

Prepared a slide deck for discussion before adding it to the specification

Updated at discussed

Review all changes in multiple calls, agreed to text updates and closed issue