Explicitly call out undefined behavior in "Universal Code table genus/version codes that allow genus/version override" section?

[daidoji]

In Universal Code table genus/version codes that allow genus/version override section we have:

All genera shall have the following codes in their Count Code table. Should the first Group Code embedded in each of these groups be a genus/version code then the parser shall switch code tables to the code table given by that genus/version code.

What happens if a genus/version code isn't the first element group code but shows up in the nth + 1 element group code? Is this strictly undefined/ignored/or do we switch tables sometimes/always?

Probably explicitly defining this or noting that its undefined is the way to go.

[pfeairheller]

"the enclosing group should be dropped"

[SmithSamuelM]

@daidoji @pfeairheller In the meeting, I know I said it should be dropped but after more thought I realized this is wrong. Correct is the following:

The presence of a genus/version count code that appears as the first element within the framed material of any non-overrideable count code (universal or not) has no special meaning as an override to the stream parser. In other words, the parser only treats the genus/version count code specially as an override only when it appears as the first count code within the framed material of an overrideable universal count code otherwise there is no special override meaning to the parser. To elaborate, the parser's interpretation of its presence is dependent on the count code framed material context in which it appears.

For example suppose some application uses a list (which is a universal but non-overrideable count code) and the first element of that list is a genus/version code. As far as the stream parser is concerned the genus/version count code is just the first element in the list. Its presence provides no special override meaning to the parser.

[SmithSamuelM]

Completed with #81