The PR required to update the dependencies, but the changes to
.depend look reasonable to me, just making dependencies more explicit.

Why do you want to enable this warning for the compiler?

In particular after a quick glance, there are many instance where in order to avoid the syntactic overhead of enabling the name-out-of-scope warning, you ended up opening some more modules. Personally, I would rather avoid local opens that can be avoided by type-directed disambiguation.

One thing I found surprising while working on this PR was that introducing
one constructor or field in the current scope did not introduce the other
related constructors or fields. I was wondering whether this is an intended
behaviour and, if yes, why it is so.

It is not possible to introduce only one field or constructor in scope?

Since this is matter of changing the coding style of the repository, l don't think that a PR is the right the place to propose this kind of all-encompassing change. I am not sure if we have a better place however.

I definitely agree with @Octachron that adding some opens to enable the warning is a net negative.

I'll note that warning 40 was purposefully disabled in #8617. It wasn't unanimous then, but even so, it makes this change more contentious. Personally, I think the warning should be off: it's not a "enforce good style" kind of warning, it's a "be compatible with ocaml versions that predates type directed disambiguation" warning.

The solution to the problem of "what is this field" is asking merlin for the type or the definition of the field/constructor. Which I think works in the compiler codebase?

(also I suspect the extra dependencies are a neutral change, not a bug fix: if c.ml uses b.ml, and b.ml uses a.ml, then c.cmx depends on b.cmx directly and a.cmx either directly or transitively (depending on the code of c.ml). My guess is your change creates more direct dependencies, hence more entries in the depend files, but same transitive dependencies, hence the build is unchanged.)

In the work on Camlboot, we actually benefit from code that "heeds warning 40", in the sense that it explicitly qualifies its constructors or only uses the latest-bound constructor in the lexical scope.

Why? Camlboot (a debootstrapper for the OCaml compiler distribution) relies on an interpreter for untyped OCaml, and the interpreter semantics relies on knowing the position of variant constructors in their declaration, not just their name -- this is necessary for example to implement polymorphic comparison in a compatible way.

(I thought this PR was a good candidate for closing because very unlikely to be picked up again, but maybe not)

Yeah, that could be a reason to enable warning 40. But you could imagine other solutions, like not using polymorphic comparison on types where the ordering of the constructors matter, or ensuring that said comparisons are annotated with ground types, or reordering constructors so name ordering and tag ordering are equivalent (btw, the poly compare in camlboot currently computes an ordering that can be inconsistent with regular ocaml because it compares tag, name, payload option instead of is not immediate, tag, payload option, so None < Some _ as it should, but only by luck due to "None" < "Some").

@sliquister I broadly agree that your alternative suggestions are interesting, but one aspect in which they are lacking is that there is no tooling to check that they are correctly enforced across the compiler codebase.

This being said, I agree with your general point that there seems to be a broad consensus in favor of using construct names out of scope, and that as a result this PR, which goes again the grain, has not gathered a consensus in favor. I would ask @shindere first, but my intuition also tells me that it will probably not get merged and could be closed.