(x, x) does not mean both halves are equal

One step earlier, then. Let (3, 4) match a plain (left, right) first, with no guard at all, so learners watch it bind. Add the equality guard after that.

Yes, and I'd split that into two predictions. Ask what the names hold before anyone asks which branch wins. For (3, 4) against the unguarded pair pattern that's left = 3 and right = 4. That alone is a concrete counterexample to the idea that a pair only matches when its halves are equal.

Then bring in the guard and ask again. Both components still get bound, the equality test fails, and selection moves on to the fallback. Keeping the two guesses apart shows where a learner's model breaks. Someone can be completely right about how names get their values and still believe a failed guard means the pair's shape didn't match.

Regex is probably where the equality reading comes from. In Perl, /(\w)\1/ really does mean the same character twice, because \1 is a backreference that has to match whatever group one captured. Anyone with a few of those under their belt sees (x, x) and assumes the same rule. Worth naming out loud. A pattern that binds and a pattern that compares can look identical, and the regex habit is a sticky one.

Ran it in the suggested order with a few learners. Plain (left, right) first, then the guard. The first prediction was easy, everyone had left = 3 and right = 4 for (3, 4). The second split them where it was supposed to. Two people said (3, 4) falls through because the pattern "doesn't match", when both names had been bound and only the guard failed.

I didn't try explaining it, since a sentence from me is easy to nod along to. I asked both of them to type the version they believed in.

let same = function
  | (x, x) -> true
  | _ -> false

The compiler refused it, saying x is bound several times in this matching. They read it twice and said "oh, so the second x is a new name", and both got the guarded (3, 4) right on the next try. Next round I'm putting that error on the screen before the guard.

A trap for the round after that one. Once learners hear that the guard is where a comparison goes, a few will move the comparison into the arm body instead, | (left, right) -> if left = right then true else false, with the old fallback still sitting underneath. The two placements differ in when they run. A failed guard sends selection on to the next case. An if in the body runs after the arm has already been chosen, so the case underneath can never be reached.

The compiler does say so, with warning 11 that the match case is unused, but it is a warning and easy to scroll past. For (3, 3) and (3, 4) both versions return the same values, so the predictions won't expose it. Only a fallback that does something different from the else branch will.