I don't understand this description. In particular, I cannot tell from it if the compiled body are ever duplicated (what if two pms can jump to me, will I appear in two different catch handlers?)

Without looking at the code (it's not clear that the code would be terribly helpful anyway), it looks like the result can be explained with the following structure:

catch
  catch
    <first body>
  with <second exit> ->
    <second body>
with <third exit> ->
  <third body>

plus the optimization that bodies whose corresponding exit-number is never used are discarded.

I tried rewriting the explanation in such a way, I'm not terribly fond of the result (I pushed it anyway), I'll let you have a look.

Wouldn't it be clearer to have the presentation of comp_match_handlers below this one, so that the jumps have been introduced (in the explanation) before you explain how they are used in the explanation? The explanation could be presented in three passes, (1) "precompilation" (into a list of blahs (what's the right name for the pms we get out of precompilation? basic pms? canonical pms? orthogonal pm? simple pms?)), (2) "compilation of each blah", (3) "chaining/linking of the bodies".

(If I understand correctly, the reason why (3) and (2) are interleaved is that if you detect, by compiling the simple pms before you, that you will never be jumped into, then there is no point in compiling yourself. That makes sense, but maybe we can explain this intensional aspect after the main explanation instead of having it influence the presentation structure?)

I pushed a commit doing that reordering.

I would name the comments and refer to the comment by name. (This is more robust to moving content to other files, etc.; and it is how GHC does it.)

I don't know how you'd do that, using ocamldoc's reference syntax?
Why don't you push that change on this branch?

I had a low-tech solution in mind, using custom markup syntax that is not recognized by ocamldoc: eg.

Note {pattern compilation overview}: ...

... see the note {compilation overview} ...

I can push this later, if you haven't done it.

I pushed something along these lines.

The _, _ part before lam5 creates a risk of confusing some of the _, _ which may be copies of this one or have been inserted by the compilation technique itself. What about using p5, q5 here? (Were you just fed up with the labeling or is there a reason to have catch-alls here?)

Actually, it's meant to indicate wildcards in the source, and the point of having wildcard in the source of the example is: that way we're sure the row won't be moved above the or-matrix.
I'd be happier with p5, q5, but we would have to add a note saying p5 <= p4 && q5 <= q4 .

I don't remember, are patterns really split into a head and the arguments (pushed into the row) at this point?

They are in cls yes.

There should be a mention that this three-body is just an example (I thought at first of writing the generic case with well-placed ... but this is too ugly). "result in a nested structure like the following three-pm example:"?