Thanks for the references! Light reading 
Your first form include (struct ... end : sig ... end) seems “clean” (it should be functionally equivalent since it does not introduce any new module type, value, etc). In fact, that would be trivial to write up in a PPX, although for reasons mentioned below I won’t.
But to be honest, i am in favour of having an
mli(because of modular compilation, it is nice for documentation and it make encapsulation and type abstraction “easy”).
modular compilation: As a thought experiment, I can imagine a transformation of a .ml file into its true .ml and .mli representation based purely on the AST, if the signature embedding is standardized (ex. I suggested module type _ : sig ... end (* rest of module *)). And since that transformation exists, that means that the modular compilation feature can be done without a .mli. Is my thinking wrong?
If my thinking isn’t wrong, I may allow embedded signatures in MlFront in the future. Currently MlFront makes a symlink from a module A.ml to its fully-qualified module path (ex. Something__A.ml). It seems easy enough to break A.ml into Something__A.mli and Something__A.ml while scanning the AST for module dependency analysis. Supporting embedded signatures would obviously be better if it were in the compiler itself, but at least in my head the interim solution sounds ok.
I’m skipping discussion of a PPX solution since a PPX would make it difficult to distinguish between signatures and structures during dependency analysis. Keeping signatures/structures separate should allow me to infer requires/exports without user intervention: Proposal: a new `exports` field in `findlib` META files