I'd like to find the best approach to packaging up fine grained libraries
that can be shared across multiple code bases while avoiding namespace
collisions. I found packs to work wonderfully, but have heard that module
namespaces have other advantages, so I'm trying to find the best approach
there.

In all of the module aliases examples that I've seen, the suggested
file/naming structures are as follows:

- myLibModuleA.ml
  open MyLib    (* So that this module can refer to short name ModuleB *)

- myLibModuleB.ml
  open MyLib    (* So that this module can refer to short name ModuleA *)

- Optionally, we can have the compiler automatically open `MyLib` in the
previous two files.

- myLib.mli and myLib.ml
   (* Reexporting short names, mapped to longer internal names *)
   module ModuleA = MyLibModuleA
   module ModuleB = MyLibModuleB


If I understand correctly, module naming conflicts are avoided because
`myLibModuleA.ml` implicitly generates a module name of `MyLibModuleA`
which is unlikely to collide with any other module written by another
developer that I compile along with - because the file name was prefixed
with something sufficiently unique. Then, users of exported modules are
encouraged to access them via `MyLib.ModuleA/B`.

But there still seems to be a couple of issues with this.
1. When reading my library code, or client's code, it's not intuitive how
to find the source of MyLib.ModuleA. Readers must first look at exactly how
they've been aliased to find the long name.
2. People may not want to prefix their internal modules, especially since
they're going through the trouble of making a mapping anyways.


Is there a way to allow internal modules to have short names, along with
those short names being reflected in short file names? I appreciate the
ability to *arbitrarily* alias modules with whatever names we wish (so I'm
not asking for decreased flexibility), but it seems critical that two
different library authors be able to have their own internal module named
`Utils` in a file named `utils.ml`. Packs allow this, and it seems if
module aliases are being encouraged as the proper way to namespace, then
they should be capable of namespacing properly. Is the following possible
with module aliases?

One set of modules that form a kind of namespaced "project" MyLib.
---------

~/myLib/myModule.ml
  open MyLib    (* This is not needed - short names are same as long *)
  (* Sees Utils belonging to MyLib *)

~/myLib/utils.ml
  open MyLib    (* This is not needed - short names are same as long *)

~/myLib/myLib.mli and ~/myLib/myLib.ml
   module MyModule = MyModule
   module Utils = Utils


Another set of modules ("project") that depends on the previous project
YourLib
---------

~/yourLib/yourModule.ml
  open YourLib    (* This is not needed - short names are same as long *)
  (* Sees Utils belonging to YourLib *)

~/yourLib/utils.ml
  open YourLib    (* This is not needed - short names are same as long *)

~/yourLib/yourLib.mli and ~/yourLib/yourLib.ml
   module YourModule = YourModule
   module Utils = Utils


Finally, an application "project" that uses the namespaces generated by the
previous two projects
---------

~/myApp/myApp.ml
let x = MyLib.Utils.x + YourLib.Utils.y

Can the first two "projects" be compiled separately, so that each sees
their own copy of the Utils module, then be linked into the final
compilation of MyApp, with namespaces properly in place? I am able to do
this with packs. If possible with module aliases, is there an example of
doing so? I couldn't find this fact confirmed/denied in the Type Level
Module Aliases paper and I expected it to be addressed because being able
to do this is fairly critical to developing large scale codebases. If not
yet possible, is there a workaround and is it on the roadmap?

Thank you for your help.