Isn't the syntactic ordering also not stable? For example:

type ('a, 'b) bpair = 'b * 'a
type _ t = Pair : ('a, 'b) bpair -> ('a * 'b) pair

is equal to:

type _ t = Pair : 'b * 'a -> ('a * 'b) pair

Indeed, but I'm not sure this is problematic here. The trouble is that the we compute constructor descriptions (with Datarepr) several times for the same type declaration, but with different substitutions applied to it, and substitutions change the ordering between ids of type variables. (In particular, we apply two "identity" substitution for the opened signature -- one caused by the loading of the persistent structure and another by open_signature; but only one "identity" substitution when computing components of Bug1.t.) The suggested fix ensures that the ordering of parameters does not change when such substitutions are applied.

I admit it seems quite brittle, though.

Perhaps to clarify: the problem comes from the fact that there are two different (incompatible) constructor_descriptions for the same constructor in the same context (one coming from the open Bug1 , the other constructed when "module components" of Bug1 are computed). I'm not very confident about it, but I believe that as long as the ordering is invariant under "identity substitution", the problem would not appear; another fix could be to implement open by inserting components from the module, instead of recomputing them from its signature.

To elaborate a bit again, I think the reason why the fact signaled by @lpw25 doesn't (currently) lead to a bug is that even if a constructor X.t.A is re-exported as Y.t.A, the internal record types for these two constructors are not considered as being equal:

module X = struct
  type t =
    | A : { x: int } -> t
end

module Y = struct
  type t = X.t =
    | A : { x: int } -> t
end

let _ =
  match X.A {x = 2} with
  | Y.A r -> Y.A r  (* ok ! *)

let _ =
  match X.A {x = 2} with
  | Y.A r -> X.A r  (* error ! *)

The error message for the last line is:

Error: This expression has type Y.t.A but an expression was expected of type
         X.t.A

i.e. the path is not normalized by taking equality of the two types Y.t == X.t into account.

@garrigue Could you please have a look at this patch?

@alainfrisch is this superseded by #834?

Yes, indeed.