Sometimes ocamlc -i generates a wrong signature, and then, either the compiler will give a "helpful" error message by saying something like ... X.t ... is not the same as ... t ..., or it says something like "val x : t is not included in va x : t", which is not helpful at all.

I guess that either ocamlc -i should never generate an interface that won't compile, or the error message for the second example (i.e., b.ml) should be improved.

In the case where it's chosen that it's acceptable for ocamlc -i to generate interfaces that won't compile, I believe it should at least give warnings or provide ways to track down the "generated errors".

I've run into this issue numerous times as well. I've stopped naming my types "t" as a result of this and a related issue [1].

I think the compiler should reject a module whose visible values have un-namable types. This augments the current heuristic that the same type name cannot be introduced in the same scope more than once.

[1] functors like Set.Make cannot be instantiated with a module with a carrier type of "t" if "t" is already visible. For some reason, type t = t is taken as a recursive type abbreviation, which breaks a common use case to support a baroque corner case (-rectypes)!

ocamlc -i originates as a kind of "verbose" option and was not implemented as a well-thought-out must-work-in-all-cases interface-generation tool.
We might want to turn it into one, but that will probably involve a large amount of work.