One shortcoming of Dylan's module system is that you cannot be more specific than names -- i.e. you can't specify the type signature of methods or generic functions at the module level.  At least Java interfaces allow you to specify the names _and_ types of methods that must be implemented.

Speaking as one of the designers of the existing module system, I strongly disagree with you on this.  It was in fact completely intentional that Dylan module definitions *don't* contain such information. 

Dave Moon explained it well, in a long-ago (3/3/94) email discussion:

    Dylan does not require programmers to make a textual copy of portions of the definitions of items exported by a module, like a C header file or an  Ada package declaration. 
In my opinion Dylan modules still have a well-defined interface; the difference is that we assume there will be the obvious development tools for printing out that interface, instead of requiring programmers to pretend to be tools and copy text from one file to  another.  (Except of course Dylan still requires programmers to copy the -names- of the exports from their definitions into the define module statement.  We haven't thought of a good way to avoid that.)

Having type signatures as part of the module system would enable better cross-module type checking and better optimization.

Having type signatures as part of the module system should do nothing to improve cross-module type checking and optimization. 

he development environment and delivery model assumed by the existing specification of module defining forms is that part of a library that one can compile code wrto and link to is some information provided by the compiler when it processed that library.  One of the things that should be in that information is the stuff needed to compile more efficiently references to the library's bindings.  Type information is only one of many bits that ought to be placed there, including such things as inlining  information, sealing, expected code size (might be used for automatic inlining decisions), expected runtime cost (again useful for inlining), and so on. Much of that can't reasonably be generated by the programmer, and really needs to be done by the compiler.  Given the existence of this repository, it seems pretty silly to make the programmer maintain two independent copies of the type information when the compiler could just as easily generate the needed information by processing the definitions instead of comparing the two copies and complaining about the occasional mismatch.