Part 6 (ver 1.04, draft 16) describes in 5.2.6 for Structure with optional fields:
"The EncodingMask is a 32- bit unsigned integer. Each optional field is assigned exactly one bit."

Part 3 draft 8 in section 8.51 StructureField (table 39) has the field isOptional which has datatype boolean.

Based on the StructureField definition it is not possible to figure out which bit of the EncodingMask describes which optional field.

The specification does not enforce any ordering of the EncodingMask bits (e.g. it would be allowed that bit number 25 would control the first optional field and also that e.g. bit number 29 would control optional fields 2,3,4), it just states that for each optional there is one bit (and 1.03 text also stated that one bit can control multiple optionals, which is still a possibility with current text).

I see 2 solutions:

1. Change data type of isOptional from boolean to 8 bit signed integer which describes which position of the EncodingMask controls this optional field (starting from 0, and keeping -1 for non-optional fields)

2. Change EncodingMask so that the first bit controls the first optional field, second bit controls the second optional field and so on (yes, this would limit the number of possible optional fields in a structure to 32, but I would assume that would be a very rare scenario and in that case the structure could be split into sub-structures which each having 32 possible optional fields).

I would prefer 2 as e.g. UaModeler does create such datatypedictionarys and secondly because in the NodeSet2 format there is also only IsOptional as a boolean meaning the complete information is not available.

Just in case it is still not clear:
As this new system should replace the TypeDictionary system or provide complete alternative, it should offer all the same information.
Spec 1.03 Part 3 Annex C of the TypeDictionary system section C.2.6 FieldType (table C.6) has the concept of SwitchField and SwitchValue, e.g. for a Structure with optionals, the following TypeDictionary is possible:

<opc:StructuredType BaseType="ua:ExtensionObject" Name="OptionalTestStructure">
<opc:Field TypeName="opc:Bit" Name="TestOptionalField1Specified"/>
<opc:Field TypeName="opc:Bit" Name="TestOptionalField2Specified"/>
<opc:Field Length="30" TypeName="opc:Bit" Name="Reserved1"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField1"/>
<opc:Field SwitchField="TestOptionalField1Specified" TypeName="opc:Double" Name="TestOptionalField1"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField2"/>
<opc:Field SwitchField="TestOptionalField2Specified" TypeName="opc:Double" Name="TestOptionalField2"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField3"/>
</opc:StructuredType>

Now if we assume above 2. option, then the information is same, however as long as specification does not enforce 2., nothing prevents from creating a structure with e.g. the first bits of the EncodingMask (the opc:Bit parts) from being reversed e.g.

<opc:StructuredType BaseType="ua:ExtensionObject" Name="OptionalTestStructure">
<opc:Field TypeName="opc:Bit" Name="TestOptionalField2Specified"/>
<opc:Field TypeName="opc:Bit" Name="TestOptionalField1Specified"/>
<opc:Field Length="30" TypeName="opc:Bit" Name="Reserved1"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField1"/>
<opc:Field SwitchField="TestOptionalField1Specified" TypeName="opc:Double" Name="TestOptionalField1"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField2"/>
<opc:Field SwitchField="TestOptionalField2Specified" TypeName="opc:Double" Name="TestOptionalField2"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField3"/>
</opc:StructuredType>
It would be allowed by the specification 1.03 and possible with the TypeDictionary, however this information would be impossible to figure out by looking the new DataTypeDefinition system OR NodeSet2 (without parsing the encoded TypeDictionary).

Also to make a point, the following would also be allowed by the old system
<opc:Field TypeName="opc:Bit" Name="TestOptionalFieldSpecified"/>
<opc:Field Length="30" TypeName="opc:Bit" Name="Reserved1"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField1"/>
<opc:Field SwitchField="TestOptionalFieldSpecified" TypeName="opc:Double" Name="TestOptionalField1"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField2"/>
<opc:Field SwitchField="TestOptionalFieldSpecified" TypeName="opc:Double" Name="TestOptionalField2"/>
<opc:Field TypeName="opc:Double" Name="TestMandatoryField3"/>

(the first EncodingMask bit controlling multiple optionals), also this would be impossible to figure out in the new system.

Note that since UaModeler creates TypeDictionarys as assumed by 2. I would assume it would be fine for the specification to enforce it. If not, then the encoding mask position information should be available in the new system (and added to NodeSet2), i.e. option 1.