I agree that the most significant issue about bit order is that it isn't really analogous at all to byte order.
Bit order is fundamentally more primitive.
I think I got fooled into thinking bit-order and byte-order were similar, because we actually have byte-order incorrectly classified. It is in the section of properties about both content and framing, and says it applies to sequence, choice, and group.
But if byte order is really about simple content only then it is not relevant to sequence/choice/group. That is probably a hold-over from when we had byte-order affecting text for some encodings. Now that byte-order of text is specified in the encoding only, perhaps byte order is no longer relevant to sequence, choice, and group. And if that is so, then, I think we have byte order in the wrong section. Byte order is in the section on properties about both content and framing, but if it is only about simple content it belongs in a subsection of section 13. We don't have a section about "all simple types with binary representation", but that's where it would logically want to sit since it is shared by binary numbers, binary calendars, and binary booleans. (Also note that in our enumeration of the binary types in the description for the dfdl:byteOrder property, we forgot binary booleans. We need the byte order if we're to compare the binaryBooleanTrue/FalseRep to a value coming from the data stream and the number of bits of length is > 8.)
But back to bit order:
Bit order, unlike byte order, truly does affect both content and framing. It affects the start position of anything that can start at a location that is not on a byte boundary. From the perspective of our data grammar, this really does mean any grammar region at all. Bit order is needed to define bit position, and bit position is needed to define the start and end of grammar regions because grammar regions start and end at specific bit positions.
So implications are that anything with alignment must take bit order into consideration, therefore sequence, choice, group as well as element and simple type. Furthermore, anything with length must take bit-order into consideration because bit order dictates how you are numbering the bit positions and therefore exactly which bits are between the start bit position and end bit position depend on bit order whenever either the start bit position or end bit position are not a byte boundary.
Perhaps we need to state exactly this. "A grammar region defines a part
of the data stream starting at a specific bit position and ending at a
specific bit position. Since bit positions within a byte are numbered
relative to the bit order, the specific bits of the data stream
corresponding to any grammar region require consideration of the bit
order any time the start bit position or end bit position of the region
are not on a byte boundary."
I should mention that implementation wise this is much easier to implement than it sounds (for parsing anyway), because it is only when you actually extract data from the data stream that you must consider the bit order, and use it if it is LSB first, to change around the extracted data so as to access the right bits. Parsing things like alignment fill, that just move counters of positions, really there is nothing to do there you just increase counters of bit position. Of course on unparsing, alignmentFill is equivalent to writing out a binary integer of a specific length, so on unparsing the bit-order does matter for regions that must be filled.
So bit order is not really analogous to byte order at all. It's a more primitive thing and belongs in Section 11.
It is only when things are byte-aligned and a multiple of bytes long that bit order doesn't matter.
That happens a lot in real data, but in DFDL everything allows for the possibility that things are not so aligned and don't have bytes-long lengths. The only things I know of that must be byte aligned are text in encodings that have a mandatory byte alignment. I think everything else can be bit aligned. Hence, bit order applies to prefix length regions, and prefix-prefix length regions, element unused regions, choice unused regions, alignment fill, skip regions, etc. It applies to anything because it affects the notion of "position" and regions are about the bits between the start position of the region and the end position of a region.
Bit order and bit-position are more primitive notions on top of which the notion of regions in the grammar are built.
This is actually a good thing, because otherwise bit order would require detailed treatment in practically every section of the DFDL spec. Since bit order underlies bit position, which underlies regions, we can define how bit order affects bit position, and then the only additional place bit order needs discussion is where it affects the values of things - decoding of text characters, and computation of binary simple type values. To the extent that descriptions of simple type conversions use first and last or most-significant and least-significant, there is no change needed because these notions are relative to bit position.
...mikeb