Tyler Gregg

I will argue that the case in which symbol tables have extra non-system fields is so rare that it is not worth optimizing for. That's because no existing Ion writer...

It sounds like we agree on the approach: to raise an error if more than one of the same system field is defined in a system struct. Is that accurate?

> Is there a reason not to go further, and reject all unexpected fields in system structs? I'm not sure we'd really gain anything by making this change. Historically we've...

I don't think there's a reason to have a special case for NOP padding here. In other words, the fields of NOP pad "values" must still be sorted properly.

> the issue of inconsistent valid representations could be resolved by requiring conversion to a particular canonical form before hashing, in the same way that the ion-hash spec resolves the...

I believe this behavior is actually correct, and all Ion parsing implementations that I've tried with this input (ion-c, ion-rust, ion-java) behave the same way. Note that this does not...

Yes, I think that would be a good test case to add to `bad/`.

The test as written should be expected to fail due to the following guidance in the `IonSystem` documentation: ``` In general, {@link IonValue} instances returned from one system instance are...

We could also create a Discussion that would allow users to provide feedback on the usability of ion-java in multi-threaded contexts.

Also apply this to `IonReaderTextSystemX.transcodeNextTo()`. Additionally, `IonReaderContinuableCoreBinary.transcodeValueLiteral()` and `IonReaderTextSystemX.transcodeValueLiteral()` are similar enough that we could consider making `MacroAwareIonReader` abstract and putting a generalized implementation in there.