So in this case it would help because the struct definition (and also metaprogramming) generated methods, so it’s not visibly clear what went wrong in those methods. Again, we’d normally follow the stack trace’s line number to the struct definition, but that doesn’t help when you already misunderstood what the struct definition did. As sgaure commented, reflection can help, but so would putting more of the method signature into the Closest Candidates printout.
Maybe for brevity? In other failed dispatch cases where there isn’t a misunderstanding of what methods were defined, this printout is intended for finding method ambiguities or mistaken input types for the call, in which case method argument names really are useless. But I personally wouldn’t be bothered by the extra information of a full method signature, and evidently it can save a few clicks and some time in narrow circumstances.
Not sure what you mean by “start” here, but runtime error messages can be modified over Julia versions because it doesn’t break code. Making the changes is just a matter of making a good argument in a Github issue, submitting a fix in a pull request, and convincing enough developers to merge it into newer patches and minor versions.