I think this is an uncontroversial change, it should be the default (not an attribute), and it's a generally part of "better pathing in error messages". I would say it's food for a tracking issue that lists the problematic cases (type aliases, reexports (e.g. error messages sometimes refer to something in core, when they should typically direct you to std); there are a couple other things in your linked issue), and tracking the ground work needed to make those changes.
I could see this being annoying for non-opaque aliases in my dependencies. It's hard to tell what's going on when relevant information is hidden -- e.g. that "type" is actually a trait projection.
A related issue I've wanted is for diagnostics to be smarter about what names are in scope. I've seen both full paths for names in scope and no paths for things not in scope. (Also, use my name if I renamed on import.)
Then if I didn't import the alias, don't use the alias in diagnostics.
I think the ideal is "use the name the developer used, and also, if they're different, the actual type relevant to the error and how they're related" - but there's lots of subtleties like associated traits and macros that make that a tar pit.
There were issues before with rustc often mentioning types as exported from ::serde::private::std::* instead of ::std::*. (Note that serde is lexographically ordered before std.) I think serde mitigated it by only reëxporting exactly what it was using, and rustc at some point learned to prefer the canonical path instead of choosing unpredictably.
Whatever scheme is used, it needs to be able to avoid accidentally preferring non-canonical paths over proper paths due to the fact they accidentally happen to score better on some heuristic. e.g. I want to see std::sync::atomic::AtomicU32, not lib::__::AtomicU32, just because I happen to have lib available, it has macros that need access to AtomicU32, and the path to the symbol is shorter (thus it surely would be preferable to the longer path).
Also, when an error has multiple source spans, it can be unclear which one is the primary source of the error. (E.g. Cargo can say which crates are nonlocal and thus likely not the culprit, but rustc doesn't have that information. The best it has is which crate is currently being compiled, but legitimately sometimes the error is better blamed on an "upstream" but still local crate, and rustc doesn't have that information.) Most errors are obvious where should host the blame (e.g. the code of the function being typechecked, not the signatures of the functions its using) but it's not always straightforward (e.g. conflicting impls).
It's fairly self evident the priority of names to use, it's just not simple to actually follow that guideline.
The name used in the code causing the error, if present.
The name in scope at the source of the error, if present.
The "most canonical" path for the name from the defining crate, if available to the crate causing the error.
The "most canonical" path that the name is accessible to the crate causing the error by, if available.