Lint against inconsistent import paths

What it does

For example, there are some import paths A, a::A, ab::A and ac::A to the object A, where A, a::A are visible to mod b and mod c, ab::A is visible to mod b, ac::A is visible to mod c.
So there are multiple choices for mod b and mod c to import A

A weaker version of this lint would warn if the import paths to the same object in the project is inconsistent and can be unified (in the first case).
An stronger version of this lint would warn if the import path to the object is not following a predefined rule (in all 3 cases), the rule can be

• use the shortest absolute path
• use the path which has the least restrictive visibility

It's not a mature idea but I think something like this is helpful.

Advantage

• the import paths are more stable against editing, producing less git diff noises
• make it easier to refactor

Drawbacks

• it's nonlocal. So Maybe it's hard to implement or it takes a lot computing resources to run.

Example

// lib.rs
pub use a::A;

pub(crate) mod a;
pub(crate) mod b;
pub(crate) mod c;

// a.rs
pub struct A;

// b.rs
use crate::A;

struct B(A);

// c.rs
use crate::a::A;

struct C(A);

Could be written as:

// lib.rs
pub use a::A;

pub(crate) mod a;
pub(crate) mod b;
pub(crate) mod c;

// a.rs
pub struct A;

// b.rs
use crate::A;

struct B(A);

// c.rs
use crate::A;

struct C(A);

Start with the issue's lib.rs, a.rs, b.rs, and c.rs examples to understand the proposed import-path equivalence and visibility rules. No implementation files or tests are named; define the lint's scope and rule first, then determine how it would analyze nonlocal imports and add coverage demonstrating the intended warnings.