Custom ignore messages definitely will be brought back. The previous problem which resulted in it's removal in the first place was the font tag and formatting being identified as spam-like by the chat servers. This caused the ignore messages to sometimes not be seen by others in the room except yourself (since it's echoed back locally in both cases by YTK). This won't be a problem going forward and it will be 100% compliant with Yahoo! Messenger's own text formatting.

Addressing the Gawd Mode concern. Gawd Mode is pretty much obsolete these days. I would like to know how your trivia bot is giving out points for correct answers for it's questions when Gawd Mode blocks all inbound (received) YMSG packets. Are you using another name in the room to give out points manually yourself or?

Gawd Mode these days is not as cool as the original and all it really is obviously is profile alias name account inactivation after chat has been entered. With the release of Yahoo! Messenger 11.0 and 11.5 (YMSGv18 and YMSGv19 respectively) you're not able to use it anymore because the chat servers simply don't support it when these protocol versions are used. To get around this you can use Messenger 11.0/11.5 and simply use YMSGv15-17 or version 102 instead, some features being limited of course but Gawd Mode will function. You'll need to enable Auto-Reconnect and select 15, 16, 17, or 102 in the control panel. There's no need to downgrade to a lower Messenger version when YTK can support them all to begin with.

In case anyone is wondering about why Yahoo! took away alias name inactivation (Gawd Mode) in YMSG protocol versions 18 and newer (19 is currently the newest), it's because of the new ability for multiple simultaneous account sessions being logged into multiple computers and different devices (mobile phones, other PC's, Yahoo! Mail Messenger etc). If any of these session instances sent an alias inactivation packet request then the server would have to block all chat communications (packets) sent to that alias and that would result in a potential problem for the global system of "never missing a message". They don't want you to be able to affect all session instances of a logged in account from a single session's decision to globally affect all other active sessions for the particular aliases. This is the answer I've come up with and it's pretty logical.