I'm not surprised. The traditional encoding on Unix is eucJP; and gettext/libc can transparently recode the message to any target format. So the catalog could be in eucJP, or utf-8, and you still could produce messages in iso-2022-jp.
I just tried it on a catalog; msgfmt complained about two problems: for one thing, it complains that iso-2022-jp is not a portable character set name, i.e. that many systems apparently don't recognize this character set name. The other problem is that it complains about illegal escape sequences. I don't know where this comes from; it might be a gettext mbcs bug, or a glibc bug, or an error in my data. If you have real data which are not properly processed by msgfmt, please report that bug to Bruno Haible.
I can't see any reason why gettext(3) would have any difficulties with iso-2022-jp.
iso-2022-jp conatins " and \ in the second byte. Big5 also.
I think iso-2022-jp is only for message transportation and not good for text manipulation like within Mailman.
I still recommend all the messages and templates should be encoded in EUC-JP within Mailman and Web Interfaces, and converting them into iso-2022-jp when mail is in and out.