This question is related to, but not the same as, https://languagedesign.stackexchange.com/q/189/30 as that questions gets into the design of handling compiler errors at the compiler level (and the answer there gives personal examples of their approach to handling them). This question is more of a philosophical one regarding how far one needs to go when offering information about a compiler error.
Rust has a reputation for extremely helpful compiler error messages, going so far as to point out the specific portion of a line that's problematic as well as suggestions to fix the error. Those suggestions sometimes perfectly account for a programmer's intentions and offer correct solutions to them.
These advanced explanations are not very common in programming compilers, and when designing a programming language, I'm curious how important it would be to sink all that time into supporting such a robust compiler error handler, or whether the seemingly much more common approach of "Solid explanatory error message with supporting documentation" is sufficient.
To narrow this down a little bit further, my intent would be to target an audience that should, ideally, have a fair bit of programming knowledge from other languages prior to starting this language's use (i.e. I don't expect this to be that discoverable or as accessible to new programmers given its scope) and am weighing my options as it pertains to the work I would put into this sort of feature.