Testing the reader in step1 is easyer because no evaluation is involved yet.

`(a (b) c);=> (quasiquote (a (b) c))

The faulty reader (in the commit before the fix referenced in issue#560) answers(quasiquote (a (b)) c). The same probably holds for other reader macros.

I don't know what the criteria are for adding tests, so I'm not sure how to answer here.

It's absolutely true that the suggested step 1 test above would catch the exact implementation bug that I managed to perpetrate - my code was indeed over-aggressively closing brackets before it should have done, hence managing to turn `(a (b) c) into(quasiquote (a (b)) c) rather than(quasiquote (a (b) c)). However, this suggested test would only catch that and not other potential subtle misimplementations.

The test I have suggested in this PR would catch a wider range of potential implementation bugs: rather than testing for a specific implementation error it instead tests for being able to successfully decompose a complex expression with multiple instances of reader macros in the correct way.

Either would have saved me from getting to the end of step A without being able to runmake "perf^mal", and I can see arguments for both tests being used: the step 1 test suggested above tests specifically for the exact bug we have found in the wild as perpetrated by me; the step 8 test in my PR tests for the whole class of such bugs, or at least some hopefully large subset of it.

Investigating macro and quasiquote expansion is difficult. I will not discuss the large test, but the short test should definitely be included in step1 for each reader macro.