added a comment - - edited
I really don't know how to explain it. The fist thing was the name itself that was too much "common" and could conflict with imported libraries or whatever. It seems that you already have fixed that.
And the second objection are the uses that you are doing of those constants, or what constants are supposed to do. IMO constants are useful to define values that are related with the normal operations of the code, in other words, well-know-values, I mean, for example, it has perfect sense to create (note it is one invented case):
And later use those constants in your code, both in conditions and sql params, and also when creating urls. It improves readability and causes, for sure less mistakes, so it's a good use of constants. There are a bunch of them being ok in you messaging code, like MESSAGE_USER_IS_CONTACT, MESSAGE_SHOW_ACTION_LINKS_IN_CONTACT_LIST... and surely more.
But those constants must nor be used for anything not being values related with the code, like request param names or SQL param keys. For example, this is correct:
$usergroup = optional_param('usergroup', MESSAGE_VIEW_UNREAD_MESSAGES, PARAM_ALPHANUMEXT);
(you are getting the value of the 'usergroup' param and applying one well-known value (MESSAGE_VIEW_UNREAD_MESSAGES) if not present)
But this is 100% wrong:
$viewing = optional_param(MESSAGE_VIEW_PARAM, $usergroup, PARAM_ALPHANUMEXT);
(getting the value of one param given by a constant. In this case, the constant is not one well-know value, but one name - one key)
Exactly the same applies to SQL named params, you can use constant as values, but not as keys. And also to creation of links, you can use constants as values but not as keys.
So, summarizing, any constant that you are using in the code as key is a candidate to be out. Constants are only values.
Not sure if I've explained the difference properly, I hope so. Ciao