I can't easily see what MMapper is sending to MUME (well I could turn off encryption and use a packet sniffer I suppose, but it's a little tedious - I'll do that if necessary) as it's not in the MMapper logs, but based on the observed behaviour seen in my client, MMapper proxies and sends to MUME (in some form) the GMCP Core.Supports messages my client is sending when my client connects to MMapper (these are configured in the client preferences, not in triggers).
However, if MMapper disconnects from MUME, e.g. with _disc, and then reconnects, e.g. with _conn, it does not resend this message and, quite likely not the client's core.hello message either as that was sent from the client earlier.
GMCP is disabled by default when connecting to MUME, so the result is that GMCP gets turned off in the client when a disconnect/reconnect happens in MMapper. This is not what users would normally consider 'expected behaviour'.
The workaround applied by current users of GMCP with MMapper and another client is to re-send the core.supports message(s) after MMapper reconnects, and then also all the Comm.Channel.Enable commands for all the channels that they wanted. But MMapper knows what the client that is connected to it wants in terms of GMCP and could (or even should, if we want a user-friendly, intuitive MMapper) re-send these GMCP commands to MUME. If MMapper detects that the client has disconnected, it could reset these variables until the client re-connects and sends it something that populates them (i.e. handling the case where the user changes client or their settings).