Mr. Wims's post was most informative; but the description of the Options > Other entry now seems misleading, but the original topic seems more generally applicably accomplished.
Mr. Argv0,
You are experiencing conflicting priorities. One one hand, you feel, "you promised". On the other hand, you feel, "change". The discrepancy is responsible for nostalgia in some cases and panic in others. This is normal; and I appreciate your efforts towards less "obfuscating" content this time. Thank you for your effort and contribution.
Any maintainer of software has a responsibility to both; and consequently must balance and include both in his or her decisions; and not neglect either. You are advocating neglecting change, Mr. Argv0. Some DLL's should become disfunctional over time; not all, but some.
So we're clear, my proposal did not require a binary incompatible change, but it is also being discussed. The staff have my permission as the OP to relocate this thread to that end.
With the WM_COMMAND window message, most people would expect the string, "echo -s $time" to cause the indicated command to be executed. Most people would expect e.g. a WM_SENDTEXT window message to cause the string "echo -s $time" to be sent to the active channel as text.
Either the docs should indicate this aberration very clearly, or the window messages should be renamed, optionally in compliance with existing binary code. That is, assuming that mIRC should be available to the public, and not require newcomers to jump through hoops, for the mere half-baked thrill of more senior users, which might not be the case; it is not my decision. The thrill we feel is just empathy with people's hopes being crushed regardless.
And furthermore, it's eminently possible that you, Mr. Argv0, are merely playing devil's advocate, but also possible that I'm projecting and you're actually misinformed about the nature of change. By all means, be my guest, please clarify.
