The composite opcodes pack a lot of information into a single S-expression "atom", e.g. i32.load_s/i8/4. My WAST parsing is structured as a generic S-expression parser followed by a transformation defined on S-expressions. The problem is that an opcode like i32.load_s/i8/4 comes in as a single atom, so the WAST-specific transform needs to be able to recognize all the variations. With something like i32.add it's practical to just enumerate the possibilities, but something like i32.load_s/i8/4 really needs WAST-specific lexing at some point in the pipeline.
If these opcodes were split into multiple atoms, e.g. i32.load_s i8 alignment 4, it would be much easier to use a generic S-expression parser.