And now, we have an argument of, "Well, lets just use one kind of element for MXP, one kind for plugins, not have support for the extended colors in the client for setting anything else..." I think you are missing the point I am trying to make slightly. You are right, its possible to do it other ways. But those don't provide colors universal to "every" place you use them, even if you wanted them to
Well, one version of entities is client side, which will work on anything you chose to do with the client. The other is server side, so if you run a mud, you can control that however you want from the server. I fail to see how these could possibly interfere with one another, since unless you are playing on a mud that you code for, you don't control everything. So there is already a way to use the a particular colour universal to "every" place that you use them.
you can't "see" what the color actually is without hand copying the element definitions into the color picker anyway, where you can't store them for future use, because it doesn't support doing that. Its not about *if* methods exist to do it, its about how user friendly those methods are to someone who just wants to use a color, but doesn't understand how MXP, plugins, etc. store them. I just think its silly to not have user definable colors, for ones they use so often in their own work that they need to have them handy all the time, without having 3 different ways to deal with them.
Press alt-8. Click on a colour. Click on "Other colour", click anywhere in the colour selector on the right. See the colour you want. Click "ok". Rename colour. If that's too difficult for most people to do, then I must be as smart as Stephen Hawking.
Lets just leave MXP out of this entirely and simply state that there is, right now, no single shared source for storing information about custom colors, which is easily accessible to "every" part of the client that might want to use them. Only plugins can take advantage of the use of XML elements in this case, the client itself, and its main script can't, nor, as I said, is there any "simple" way to visually see what the heck the colors actually are, without going into the color picker anyway (or using some other indirect method, like sending a colournote to the output with that color in it).
The custom colours can be used by scripts, ColourNote, they are easily accessable from the trigger menu, and can be put into plugins. I personally would rather convert the colours into hex using the colour picker (and you can just click on the values for MXP, VB, Jscript, and Lua) and copying the value into plugins I distribute so that I am not relying on any colours.