Automating generation of argument error messages

Question

You can run into messages like

DistributionFitTest["kk", "TestConclusion"]

DistributionFitTest::rctnln: The argument kk at position 1 should be a rectangular array of real numbers with length greater than the dimension of the array. >>

or

Image["hi"]

Image::imgarray: The specified argument hi should be an array of rank 2 or 3 with machine-sized numbers. >>

indicating that there is something wrong with the types of arguments passed to these functions.

Can we somehow get a formal (i.e. in the WL, given as a pattern expression, say) definition of arguments that the built-in functions accept? Maybe through WolframLanguageData?

If you have the source code of the function you can of course look at the code and the pattern matching that is done, but it looks like we are out of luck here?

If DistributionFitTest where written in WL, it might have been specified with the following argument pattern matching the description given in that error message (noting that "rectangular array" = MatrixQ):

DistributionFitTest[data_ /; MatrixQ[data, Real] && Length@data > Dimension@data, ...]

(yes there's something wrong with the last comparison, but you get the point)

Image might be defined with

Image[data_ /; ArrayQ[data, 2|3, MachineNumberQ], ...]

My main question is, is there any package that automates the creation of human-readable error messages from such specifications, at least in simple cases?

Converting

ArrayQ[data, 2|3, MachineNumberQ] to an array of rank 2 or 3 with machine-sized numbers

should be doable, but I guess most of those error messages are written by hand?

---

Aside

What is the convention for naming argument count/type errors? I.e. in the above examples we have Image::imgarray and DistributionFitTest::rctnln which seem to relate to the exact nature of the argument type error, but it's hard to tell what exactly they mean given their mnemnonic character.

It seems that ::argx is often used to indicate errors with argument counts, but e.g. Select gives Select::argb.

Also, why are message names besides usage commonly so mnemnonic when the rest of the language is not? This seems like a bad design choice that will probably stick around.