I'm of two minds on this issue. First, rustc is definitely not perfect when it comes to diagnostics, even if it's often really good at providing suggested solutions to common problems. This might lead to expectations that it should be just as good in all situations.
A recent example appeared in Overflow evaluating the requirement in a Iterator. Where the compiler was creating an infinitely recursive type from a recursive chain of Iterator adapters. (The code in OP never evaluates the chain of iterator adapters.) The error message is definitely unreadable, a lot like what we used to experience with Future adapters before async fn raised the abstraction level. These problems do happen in practice!
On the other hand, &*foo exists for good reasons [1]. This is not a fundamental shortcoming. It's a feature!
While better diagnostics could be helpful, I don't know what could be realistically accomplished by suggesting the library authors reconsider their API. Presumably they have good reasons for exposing their own reference types. I am not interested in digging into these reasons, but this is a good stance to start from.
If you can prove that these references are not needed and it results in a notable improvement for library users, submit a PR! Or worst case if it's rejected, fork the library.
See Chesterton's fence for why it is important to recognize that things exist for a reason, even if you are unaware of what that reason is. ↩︎