While implementing bulk memory proposal in my parser, I've noticed regressions in some core spec tests. In particular these two are very representative:

Here, a 0 table index (the only one allowed previously) is encoded in a suboptimal form of 0x80 0x00.

The new layout used by this proposal relies on the table index previously being always zero and encoded as 0x00, and assigns a different meaning to byte at the same position as 0x80 and expects it to be one of the following values:

Such long form is likely not something used by implementations in the wild, but it might be worth double-checking and either supporting such long form too, or at least making an explicit decision about this backward-incompatible binary representation change and removing (?) corresponding tests.