About that missing type constructors problem. Seems doable:

module A = struct
  module T = struct
    type t1 = ...
    type t2 = ...
  end
  include T

  let foo _ = ...
  let bar : t2 -> t1  = ...
end

module B = struct

  include A.T
  let foo, bar = A.( foo, bar )

end

Obviously, not for already existing code.

În sâm., 16 iul. 2016 la 10:41, Petter A. Urkedal <paurkedal@gmail.com> a
scris:

> On 15 July 2016 at 18:13, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> > And that's a real problem -- that fact that openning a module can fill
> > the namespace with lots of stray identifiers, which the user does not
> > control.
>
> Apart from the selective opens discussed, it would be good to tell
> apart which modules are meant to be open and which are intrusive
> without looking through them.  Most importantly the writer of the
> library should be clear about it from the start when designing a
> module, then the names will be consistent with the choice, and users
> should be able to decide without evaluating the whole interface.
>
> A warning when opening an invasive module in a global scope could
> help, as well.  One could maybe decide a module to be invasive from a
> few heuristics with fall-back to a declaration:
>
> - A module interface defining a single-letter identifier, most
> importantly a type "t" or a signature "S", is invasive.
> - A module interface overriding any operator (or identifier?) defined
> in Pervasives is invasive.
> - A module interface declaring itself `[@@@ocaml.invasive]` is invasive.
>
> Conversely the user may silence the warning with `open M
> [@@ocaml.invasive]`.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>