I've been wondering if it's worthy qualifying project packages at crates.io by organization.
One reason I see is that it allows versioning projects that have the same name by author. For example, consider the readability comparison from:
use hydroper_air::display as d1;
use harman_air::display as d2;
use hydroper::air::display as d1;
use harman::air::display as d2;
use com::hydroper::air::display as d1;
use com::harman::air::display as d2;
I think this would matter since "air" is a very common name, and different companies like to own products with such name.
RFC: Packages as (optional) namespaces by Manishearth · Pull Request #3243 · rust-lang/rfcs · GitHub has some discussion of why it goes for project namespace ownership rather than organization namespace ownership.
I was betting that the feature being added to Cargo is focusing on solving only the needs of logical organization of projects, typically containing procedural macro crates.
That RFC is focused on providing more options for designing APIs and doesn't as much touch on namespacing by owner. Namespacing by owner is a topic that comes up fairly regularly here with a bunch of trade offs. Most recently, Adam Harvey presented on it at PackagingCon, see https://www.youtube.com/watch?v=1IINSW7IG-k&list=PLl386dCR5QGTElF3MbltCJupNG1lHK4Nr&index=11
I wish at this point we had a document summarizing all of the namespacing-by-organization discussions to make it easier to tread new ground rather than re-hashing the same topics.
In my opinion, there is no readability improvement here, and certainly not one that would justify the operational and usability complexity added to crates.io that would be needed to support this.