- 'use' statements are relative to the root of the crate, not the current module. To work around this, you can write 'use self::name' or 'use super::name' for relative imports. Annoying but no big deal.
- If you import a symbol into module 'a', it doesn't also get added to 'a::b'. I don't know why I keep expecting this.
Once I learned these two things, Rust imports were easy.
I'm not sure I agree with withoutboats' proposals. His chnages would make several obvious things work the first time, but at the expense of taking a simple, easy to explain rule and replacing it with something implicit and mysterious.
The bigger Rust learning curve issue is making friends with the borrow checker. I like the borrow checker. It has my back, even when I'm trying to write fast code that would be recklessly abusive of pointers in C. But I can't deny that it took me a week or two to make friends with the borrow checker.
I'm writing an application. Inside main.rs I can write
extern crate foo;
extern crate foo;
One thing that might be confusing is that `main.rs` is the entry file of binary crates, while `lib.rs` is the entry file of library crates, and a project can contain both a binary and a library crate. The binary crate then does need to `extern crate` the library crate.
We've been working on a new version of the book, if you have time, I'd love if you would take a look at the new chapter on modules  and file PRs or issues on the repo  if it's still confusing or leaving you with unresolved questions!
 - http://rust-lang.github.io/book/ch07-00-modules.html
 - https://github.com/rust-lang/book
My typical use case is importing definitions, for example an error type or enum from the crate, let's say something from tokio_core.
I'd like to use this enum both in main and in my module; from my (limited) experience, you need to extern crate tokio_core both in main and the module, then use the definition. In this case the syntax is different for somewhat obscure reasons.
I made a simple example with just two files: (In the meanwhile I realized that my first example was wrong :)
Let's say that after my refactor, I've "moved" the crate import into the module since "logically" it belongs there. In this case the compilation fails if I don't use self::. But previously it was working in main.rs! And I have no idea why...
I always leave "extern crate" in the crate root; then it all Just Works.
Which is ironic, considering the premise is that the module system is "too confusing". Having never used Rust, the current rules - as explained by the author himself - seemed straightforward. For the proposed new rules, I'm confronted with two long paragraphs.
I didn't bother to read them. If the intent is to make the system less confusing, there should be a way to explain the new rules as tersely as the old ones.
That being said, I do feel that the union of a confusing and simple system can often be a more confusing system so I'm wary of this proposal reducing complexity.