First-Class Modules: Type Escaping from Unpack Signatures

OCaml's first-class module mechanism, mediated by `pack` and `unpack` expressions, introduces a documented constraint: the locally abstract type generated by `unpack` is intentionally confined to the expression scope to preserve type safety across alternative module implementations. This design enables dynamic dispatch and dependency injection but raises a practical question when module values carrying concrete types must traverse module or function boundaries without signature erosion. The precise goal is to map the exact conditions under which a type defined inside a `pack`-encapsulated module can be referenced and unified externally while respecting the signature's abstraction boundary. Current OCaml semantics prevent such escape by construction, yet the boundary behavior with higher-order module parameters and recursive signatures remains an area of design tension.

• Can a type instantiated within an unpacked module be safely promoted to a globally visible abstraction without altering the enclosing signature?
• How does functor application compare to first-class module packing when the objective is maintaining type identity across parametric polymorphism?
• What compiler mechanisms, if any, exist to relax the local abstraction constraint for types whose signatures are explicitly exported via `include` or `module type` extensions?