There are different combinations of configuraiton options that make no sense or are invalid.
Only header layouts define 'valid' or 'useful' combinations. Otherwise there is no dependency defined between configuration parameters.

If a configuraiton is invalid or cannot be used by the application within its context, the corresponding PubSub objects are set to Error State.

What MatthiasD writes in the note https://opcfoundation-onlineapplications.org/mantis/view.php?id=5379#c12219 is correct, but does not apply to this case.

The configuration I described does not fall into category "...configuraiton options that make no sense or are invalid.". It is quite meaningful, and only the missing order of datasets prevents it from being usable.

And conversely - I think we cannot ever make it usable by specifying header layout only, because order of the dataset messages is an information that belongs to the mapping part of the spec, and not to the header layout.

And, do we have any header layouts for JSON at all? I though the intent was to provide maximum flexibility for interop with other systems by allowing all kinds of possible combination, so this is precisely is the case which should be allowed, in case the other system we are communicating with wants this layout.

After the discussion in the meeting today we agreed that this is an invalid configuration.

Agreed to no-fix in virtual F2F.