When you give a block as the body to the MODULE function in R3-Alpha, you lose essentially any bindings you had in it:
r3-alpha>> obj: make object! [print: func [x] [lib/print "unused override"]]
r3-alpha>> m: module [] compose/deep [test: does [(bind 'print obj) "Hello"]]
r3-alpha>> m/test
Hello
So we put a PRINT word bound into OBJ inside that module material, but it got wiped out and used the plain old LIB/PRINT instead.
There's an UNBIND/DEEP call right in the implementation of the R3-Alpha MODULE function, so that's at least one reason why. But there are more reasons...it kind of just...doesn't work to leave the bindings on. There's too much potential for stray bindings you never intended to have meaning being treated as legitimate.
The very confusingly-named /MIXIN refinement is actually a very blunt tool for passing an object to bind to before the body runs:
r3-alpha>> obj: make object! [print: func [x] [lib/print "mixed in!"]]
r3-alpha>> m: module/mixin [] [test: does [print "Hello"]] obj
r3-alpha>> m/test
mixed in!
So now you know why that exists. Since it's going to throw away all your bindings, it gives you at least one chance to inject some overrides.
Module Inheritance May Give New Possibilites
One of the key things I want to see is the ability to say that a module uses a baseline other than the default LIB.
For example: If you want to run a module of Rebol2 or Red code, then you would want to use Redbol as the "lib" (and then perhaps expose Ren-C's functions via a "newlib" variable)...
Anyway, the point is that I think you basically have to accept that whatever you toss at the module in terms of a body will have its bindings completely lost. You have to use a facility like /MIXIN or module inheritance.