// Unions with extensibility MUTABLE, version 2 encoding
// see (22) for serialization of MMEMBER using version 2 encoding
(27) XCDR[2] << {O : MUNION_TYPE} =
 XCDR
 << { DHEADER(O) : UInt32 }
 << { O.disc : MMEMBER }
 << { O.selected_member : MMEMBER }?

The specification says the discriminator should be treated as an MMEMBER, but it is not clear what the member ID of the discriminator should be. This has caused interoperability issues as different vendors are using different IDs.

In Kongsberg's implementation, we've been using 0 for the discriminant. The first member of the union has thus had the member ID 1 (assuming @autoid(SEQUENTIAL)).

The description of PUSH states:
```
Pushes the specified XCDR stream variable VARIABLE
into the stack and sets the current value to <newvalue>.
The notation <?> indicates that the new value can be
chosen by the implementation.
This action is reverted by the POP() operation
```
However the first serialization rule that writes the HEADER calls `PUSH(ORIGIN=0)` after writing the ENCHEADER, even though it's already been set to 0 on initialization. PUSH(ORIGIN=0) is also called after writing PL_CDR headers. I'm confused as to what this is supposed to mean. Based off of the current definition of PUSH I would be lead to believe that it truly does set the origin equal to 0. However looking at it's usage I would think that PUSH(ORIGIN=0) should mean that the origin is reset to where the current offset is, and based of of what I've seen in PL_CDRv1 messages with 8 byte members, this has been a correct assumption.
Another confusing element around the usage of PUSH is that I don't see POP used anywhere in the Serialization rules.