The fact that this problem took 25 years to fix is maybe the more damning thing. It wasn't a bug, exactly; it was a usability problem. Clearer demonstrations of development priorities could hardly be given.

That was mostly a man-power issue. The good news is that nowadays such nonsensical error messages are near the top of my personal development priority for OCaml.

During those 25 years OCaml gained native-code compilers for new architectures, labeled arguments, and polymorphic variants, among other things. How could it be mostly a manpower issue?

Work and time contributed by open source collaborators on their free or academic time cannot be magically converted from one subsystem to another. It is honestly very easy to have progress on the aspects that spark interest while some subsystem are starved from attention when there are no full-time developers working on a project.

That's true, but that doesn't mean there was no manpower to fix that error message; it meant that fixing it wasn't a priority to the people who were working on OCaml at the time. You're just offering an explanation for why it wasn't a priority: fixing it didn't spark their interest.

And the REPL should warn you that if you have a value of type "t/n" it is probably a left-over from a previous definition of type t in the session.