I am a huge fan of variant 2, and I’m a bit taken aback by this thread because I thought there was more consensus around that version from previous discussion.
The issue for me with variant 1 is that it “unbalances” the namespace. I think of the crate:: prefix as a stand-in for current_crate_name::, which is important because 1) idiomatic Rust uses multiple crates with the same name (a library and a binary) and 2) it’s like self in that it enables you to rename a crate without a huge diff. (This is also why ::self and ::super don’t really make sense to me- they’re not crates and thus not top-level items in the namespace hierarchy.)
With this in mind, variant 2 places crate:: and some_dependency:: at the same level in the namespace hierarchy, while variant 1 and the status quo place the contents of the current crate one level higher in the namespace hierarchy. Variant 1 avoids some specific pitfalls here, but it feels klugy to me because it doesn’t match other languages which place every library’s namespace at the same level.
One other important point that came up in previous discussion is that std::-in-expressions only works in the root today because of an implicit extern crate std which follows the same behavior as other dependencies. To make it work with extern crate, we could simply add use std to the prelude and let it work everywhere, making it less of a special case without contorting the namespace hierarchy.