I would prefer only a clarification in documentation. What "word" you use for the command is irrelevant. It doesn't really matter if you assume that it means something different. The command could be called "WM_GO" and it would be work the same way. The edit box is also called a command line, so it makes sense that WM_MCOMMAND is treating the text as if you're sending the same thing from the "command line". And if you send something from the command line without a / or alternative command character, then it will be treated like text. I really don't see why this is such a problem to understand.
In the end, think about what you are suggesting... You want the syntax to change so it makes more sense to you. This offers no real benefit other than that you think it makes more sense. And it can easily cause scripts to stop working. So it offers no real value and breaks existing scripts that people rely on. That's not a good option. Using your wording, a maintainer of software has a responsibility... he or she needs to look at the benefit of making a change compared to the problems caused by that change. And there just isn't anywhere near enough benefit to warrant this kind of change. As it's been pointed out, / always works regardless of settings and that was your only real reason why it should change.
Could this be done without breaking any scripts or DLLs? Perhaps. But does it offer any real value? Not really. So is it worth the time to do it? No. You talk about making new users "jump through hoops." Consider this... new users to the language already have to learn the language and learning what WM_MCOMMAND means isn't any different than learning what $gettok() means or any other part of the language. On the other hand, old users (of the scripts, not old scripters/programmers) already have working scripts. A change that breaks their script will force THEM to "jump through hoops" just to get their scripts working again. You'd be forcing far more people to "jump through hoops" by breaking existing scripts. And the reality is that a very large number of users don't script, but use old scripts that are no longer maintained, but which still do what they need. There has to be a real good reason to make a change that can break scripts and syntax isn't a good reason.
Just because you assumed that COMMAND meant "EXECUTECOMMAND" doesn't make it bad. A simple clarification in documentation would resolve this very well without affecting any users. That's what I would recommend.
