I generally follow this pattern for error (or warning) message identifiers, where things in parentheses may or may not be present:
(className):(parentFunction):functionWhereErrorOccurs:descriptiveMnemonic
The components are:
className: The name of the class, if the function where the error occurs is a method/constructor.
parentFunction: If the function where the error occurs is a subfunction in an m-file or a nested function, this would be the primary m-file function or the parent of the nested function, respectively. You could therefore have multiple parentFunction components.
functionWhereErrorOccurs: The name of this component is pretty self-explanatory. ;)
descriptiveMnemonic: I stress descriptive. For example inputError doesn't really tell me anything, but notEnoughInputs makes it clear that I didn't pass enough arguments. I always use lower camel case for the mnemonic, where the first letter of a word is capitalized except for the very first word.
The className and parentFunction components could be considered somewhat redundant, since the stack property of the MException class already identifies a complete path to the parent m-file and the line number of the error. However, one of the purposes of a message identifier is that it allows you to uniquely identify an error for purposes other than just hunting down the source of the error.
Let's say you have a function myFcn and a class myClass that overloads myFcn. If you make an error message identifier for the first one be myFcn:maxIterationsReached and an error message identifier for the second one be myClass:myFcn:maxIterationsReached, this would allow you to, for example, set a breakpoint with DBSTOP that halts execution only when this error is produced by myClass\myFcn and not myFcn. Likewise, unique warning message identifiers are useful in that you can specifically choose to ignore warnings from specific functions while letting others be displayed.
Additionally, you could also include components in the identifier indicating that the function where the error occurs is located in a package folder or a private folder (but this might make for a rather long identifier).