Method / Type error verbosity & semantics

An enhancement question:
Can the types displayed in MethodErrors be made more succinct? In using Unitful, 99% of the time arguments are called with the wrong unit type and it would be great to display type symbols rather than the full signature.

Eg, with Radian defined in,

using Unitful
f(a::Unitful.Length) = @show a
julia> f(1u"rad")

currently gives

ERROR: MethodError: no method matching f(::Quantity{Int64, NoDims, Unitful.FreeUnits{(rad,), NoDims, nothing}})
Closest candidates are:
  f(::Union{Quantity{T, 𝐋, U}, Level{L, S, Quantity{T, 𝐋, U}} where {L, S}} where {T, U}) at REPL[2]:1

julia> f(1)
ERROR: MethodError: no method matching f(::Int64)
Closest candidates are:
  f(::Union{Quantity{T, 𝐋, U}, Level{L, S, Quantity{T, 𝐋, U}} where {L, S}} where {T, U}) at REPL[2]:1

I’d like instead:

julia> f(1u"rad")
ERROR: MethodError: no method matching f(::Radian)
Closest candidates are:
  f(::Radian)

Is this limited by julia’s type handling / error machinery, which have no knowledge of or ability to receive a human-friendly type name?

Stated differently, I’d prefer to display the most Abstract type rather than the most primitive in the type tree. If I define

julia> abstract type Length <: Unitful.Length end # this line doesn't work, I can't figure out the right definition...
julia> g(a::Length) = @show a

it’s more natural to show MethodErrors using the AbstractType in the function parameter types than showing their resolved type, which the user shouldn’t need to know.
(To be clear, using type machinery to model physical units is not a quixotic search for performance; instead it is to use a language and environment feature to help users manage complexity and increase productivity.)

Something like that would need to be opt-in, probably. As many people would like their error messages to be precise.