I’m not sure what such laser precision would buy us. The public dependency graph-based ordering is simply intended to minimize unexpected breaking changes due to the addition of a trait method.
Let’s say that
std::iter::Iterator had a method named
foo. There are two ways this could come about. Either:
stdhad it first. When the author of
itertoolsadds it, they are surely aware of the existing method in
std, and must be acutely aware that this could be a breaking change for downstream code.
itertoolshad it first. The author could not have foreseen its inclusion in
stdcannot afford to stop adding features just because
itertoolsexists. But there are crates out there which use
Itertools::foo, and these should continue to use it. (this is why the public dependency-based ordering prefers Itertools)
If a downstream crate wants to switch to std’s foo, they can achieve this (abeit verbosely) by writing their own extension trait that calls the std method; this will take precedence over Itertools.