The new proposal seems less radical than the one from the previous blog post, which is good. I also find more in it than I agree with, unlike last time where I didn't agree with almost anything.
Let me start with the stuff I like: The from <crate_name> use <path>; syntax is really really great! I'm a big fan! This is actually an improvement over the status quo, which doesn't allow you to know whether something is taken from a module, or from a foreign crate. If this syntax gets adopted, I'm even okay with extern crate being deprecated! Maybe we could make it part of RFC 2088, to make usages without extern crate only possible through from use. Bikeshedding syntax, I'd like to suggest an alternative: crate use <crate_name>::path;. EDIT: another alternative: extern use <crate_name>::path;.
Regarding making use <foo> relative, I'm mostly neutral. It has its merits, but generally every change has its costs, so this has advantages and disadvantages.
I still dislike the removal of mod syntax. With it removed you can't extend them via implicit mod foo any more, which would be sad. Underscores are ugly in my eyes.
I also dislike treating modules as pub(crate) per default without giving a way to do private modules. You should be able to have finer grained privacy than private, pub(crate) and world-public. Especially, I disagree with this statement:
As has been argued on thread, the vast majority of the time you only need visibility at one of three levels: the current module, the crate, or the world.
This is maybe the case for smaller crates, but bigger crates with more complexity do need finer structuring. There is no way to enforce that your submodules are private with the proposal; anything pub(crate) inside them may be exposed. My major pain point is not even that they are pub(crate) by default, but that there is no option to make it less private. Previously, we didn't need syntax to make stuff less private, because everything was private by default. But if we change the default, we need to introduce syntax for enforcing privacy.
One thing I do like though, which is that modules need an explicit pub use in order to appear in the public API of a crate.
Regarding the "use ing submodules" knob, I'd like that submodules are not in scope of their parents automatically, but you need to use them. Anything that's implicitly in scope is not really nice IMO, and the infer extern crate RFC also got modified in that regard.