The reordering you propose, Felix, looks good to me.
That said, it probably makes sense to write a formal specification (without examples and rationales and motivating text) from scratch and then weave it into the main text.
E.g. something along the following lines (written down too quickly to foreclose any mistakes and with a lot stolen from the R7RS):
**
(match <expr> <clause> ...) [SYNTAX]
=> [AUXILIARY SYNTAX]
Syntax: <expr> is an expression. Each <clause> has the form (<pattern> <body>) or (<pattern> (=> <failure>) <body>), where each <pattern> is a pattern, <failure> is an identifier, and <body> is a body as defined by the R7RS. It is an error of <failure> is one of the pattern variables.
A <pattern> is either an identifier, a constant, or one of the following
(<pattern> ...)
(quote <datum>)
(? <predicate> <pattern> ...)
...,
where <predicate> is an expression and <datum> is a datum as defined by the R7RS.
Semantics: <expr> and the <predicate>s appearing the <pattern> are evaluated in an unspecified order. It is an error if any of these evaluations yield no or more than one value. It is an error if any <predicate> does not evaluate to a procedure taking one argument. The value of <expr> is the matched against each <pattern> in order. If the value does not match against a pattern, matching is continued with the next. It is an error if there is no further <pattern>. If a value does match a pattern, the match variables of the patterns are bound to fresh locations holding the matched values. If the corresponding clause is of the second form, <failure> is bound to a special continuation that takes no argument. Then the body is evaluated in the extended environment. If the last expression in <body> returns, further matching is abandoned and the resulting values are returned to the continuation of the match expression. Each binding of a pattern variable and the binding of <failure>, if present, has the <body> as its region. Invoking <failure> abandons the current continuation and continues with matching against the next <pattern> in order. It is an error if there is no further <pattern>.
An identifier within a pattern can be an underscore (_), ?, .... All other identifiers appearing within a <pattern> are pattern variables.
Pattern variables match any value.
Underscores also matches arbitrary values but are no pattern variables.
When a value is matched against a pattern of the form (<pattern> ...) and the value is not a list of as many elements as there are <pattern>s, the value does not match the pattern. Otherwise, the elements of the list are matched against the corresponding <pattern>s in an arbitrary order. If an element does not match one of the <pattern>s, further matching against the <pattern>s is abandoned and the value does not match the pattern. Otherwise, it matches the pattern.
A pattern of the form (quote <datum>) matches a value if <datum> is equal? to the value.
When a value is matched against a pattern of the form (? <predicate> <pattern> ...), the procedure yielded by the evaluation of <predicate> is applied to the value. It is an error if this application yields no or more than one value. If it yields #f, the value does not match the pattern. Otherwise, the value is matched against the <pattern>s in order. If it does not match one of the <patterns>, further matching against the <pattern>s is abandoned and the value does not match the pattern. Otherwise, it matches the pattern.
**
-- Marc
PS There are still a lot of inaccuracies in the document; for example, at one point patterns are called expressions (which they aren't); somewhere else, the ellipsis is called a pattern (what it isn't). This does not cause misunderstandings but should probably be corrected in the final version.
PPS Some other things should be specified as well, e.g. when and how often certain forms are evaluated, e.g. the <predicate> in the ? pattern.