Testing indicates that the bug was introduced in 4.07 (.0 or .1), and is absent from 4.06.

Bisecting indicates that d43ccfc introduced the bad behavior. cc @trefis @garrigue
(see #7618)

The bug seems caused by incorrect row-variable information for the scrutinee type of f.id x -- obtained by instantiating a first-class polymorphic type. (This smells like the kind of irritating issues that, besides the two above, @lpw25 would also know about)

The following patch, which simply disables the use of presence information for better pattern-matching compilation, makes the issue disappear.

diff --git a/lambda/matching.ml b/lambda/matching.ml
index 07639abac8..c28a5ec7c4 100644
--- a/lambda/matching.ml
+++ b/lambda/matching.ml
@@ -1807,7 +1807,7 @@ let divide_variant ~scopes row ctx { cases = cl; args; default = def } =
         in
         let head = Simple.head p in
         let variants = divide rem in
-        if row_field lab row = Rabsent then
+        if false && row_field lab row = Rabsent then
           variants
         else
           let tag = Btype.hash_variant lab in
@@ -2895,7 +2895,7 @@ let combine_variant loc row arg partial ctx def (tag_lambda_list, total1, _pats)
       (fun (_, f) ->
         match row_field_repr f with
         | Rabsent
-        | Reither (true, _ :: _, _, _) ->
+        | Reither (true, _ :: _, _, _) when false ->
             ()
         | _ -> incr num_constr)
       (row_fields row)

(Performing only the first change suffice, but I think requiring both is important to avoid inconsistencies cropping up.)

This is of course not the right fix: the row-variable presence information should be correct.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

This (rather serious) bug is still present in trunk (as of c534f97).

Sorry, I had completely overlooked this one. Probably @gasche 's analysis reassured me that it was in good hands...
There is no a PR which I believe does the right thing. It may just create warnings if one uses GADTs under polymorphic variants.