Peyton Turner

Per the [binary specification](http://amzn.github.io/ion-docs/docs/binary.html#2-and-3-int) _every_ representation of 0 other than `0x20` is invalid. > _If the value is zero then T must be 2, L is zero, and there are...

I suggest removing the parenthetical, since it does not qualify or clarify any of the statements in the section. I think the spec would be perfectly clear were it written:...

> We will need to opt for a solution like your option 4 above. In other words, we must prohibit repeated field names for _system fields_ in _system structs_, and...

> That's because no existing Ion writer implementation that I know of will actually write open content within symbol table structs, and I don't think there is really a use...

I'm not opposed to that solution. Is there a reason not to go further, and reject all unexpected fields in system structs?

> Right now, we at least support reading such symbol structs with correct system semantics, even if the open content would be lost on round trip. It seems like this...

That seems reasonable, and is the impression I get from the spec. But it has the bizarre consequence that writers "should" not insert NOP padding anywhere other than the beginning...

I get the impression that the issue of inconsistent valid encodings also exists for positive zero. The spec for [binary decimals](https://amzn.github.io/ion-docs/docs/binary.html#5-decimal) gives > The subfield [coefficient] *should not* be present...