Sam Tobin-Hochstadt writes:
The module system is pointlessly inflexible, and requires additional boilerplate beyond that in R6RS and other existing implementation-specific module systems. Rather than lifting the restrictions present in other systems, it adds more, necessitating terrible additions such as include.
As for additional boilerplate, only a little is actually required. You can convert an R6RS module into the draft's module language by changing library to define-library and wrapping everything except the import and export declarations into a begin library declaration. (Of course, this assumes that the implementation provides both R6RS and R7RS modules for import on equal terms, as Sagittarius Scheme does.)
The draft's design provides the freedom to merge module interface and implementation seamlessly, as R6RS does, or to completely separate them, as Scheme48 does. This is in my view an excellent example of where the draft has lifted restrictions rather than imposing them.
The WG decided by unanimous consent to take no action on this ticket.
The R6RS module system is likewise basically static. The only way to extend it is through the use of syntax-case macros, which were considered to be too complex and controversial for R7RS-small. Note that include, however terrible (and I don't think it is) is possible in the R6RS system, but not in a way that any static tool can analyze without making arbitrary presumptions. Static analysis of R7RS modules is straightforward, as is extensibility at the level of the implementation. Not everything in Scheme has to be maximally flexible.