I get that this is basically taken from ML, but you're not doing yourself any favours by ignoring the fact that you're still presenting the featuring in ML-like syntax, not Rust-like syntax.
I'm ok with this until the end, where you start wandering off into crazy-land trying to turn Rust into ML. The core idea of "parameterized modules" has been floated around before. Being able to define type parameters for an entire module is ok. However, I very much don't agree that the benefits of being able to write abstract mod instead of using a unit-struct that implements a trait outweigh the costs. As far as I can tell, you don't actually justify that point at all, you just say "until the end of this post" and then expect the reader to be swayed by your examples.
In fact this entire proposal is rather "obviously this is the best way". There is little-to-no discussion about the potential drawbacks of this feature, which suggests that you haven't really thought about any. Furthermore, as @huon says it's unclear why this proposal is superior to merely expanding existing features.
This is entirely false. Essentially all non-trivial additions to the language increase complexity. This is not somehow special simply because you say it is. The first place I can potentially see additional complexity is in type inference, as any change to the type system inevitably affects type inference.
This isn't true, at least not with the RFC as it currently stands. The ability to specialize an impl over an existing one is dependent on the more-generic one opting-in. You won't be able to arbitrarily override a blanket implementation unless the blanket implementation allows it. Extension traits aren't going to be broken if/when impl specialisation happens.
Echoing @huon: I haven't been following along, apparently, as it's not obvious to me. You make a lot of behind-the-scenes assumptions that don't really play out very well. Notably the weird Filesystem thing. It's not at all clear what it's supposed to represent. I get that it's "just an example", but it doesn't make sense. You show examples of opening files, but the file system to use is dependent on where that file is. If you're presenting something closer to a driver, then I find it hard to believe that there is no state required at all, not even, you know, the name of the partition you're talking to. Once you take into account that state, your "obvious abstraction" isn't actually the same as the previous examples since it discards the state.
The majority of this proposal is unclear both in what it's trying to propose and the real value thereof. It comes across more as praise for ML's module system than it does a sincere attempt to improve Rust. It may very well be a sincere attempt to improve Rust, but the single-minded focus on copying ML is telling. You say you want the features to arise naturally from a discussion about code reuse and polymorphism, but it's clear that you are actually working backwards from your conclusion.