The issue is not really local open but the interaction between open, module name collision and the local nature of ocamldep analysis. Your example can be simplified to
open Database
open Actor
The issue is that without knowing the module type of Database, open Actor can either refer to the compilation unit Actor or an eventual Database.Actor submodule. And when computing dependency, we don’t know yet the module type of Database since we don’t know yet how to compile Database. The standard dependency ocamldep tool resolves this issue by computing an over-approximation of the dependencies of a compilation unit using only local information.
In our example, from the information at hand locally, the module Actor in
open Database
open Actor
might be the compilation unit Actor, thus ocamldep counts this open Actor as an Actor dependency.
The advantage of this approximation is that ocamldep might compute some spurious additional dependency but it is not missing dependencies (excepted in some known corner case).
It is possible to resolve (nearly) exactly module dependency with a project-wide analysis, this is the aim of my codept tool. But in practice, there has been limited interest in integrating codept to dune.