The XmppClient functions handleMUCMessage, handleMUCParticipantPresence, handleMUCSubject, handleMUCError receive a glooxwrapper::MUCRoom as the first argument.
That argument is currently unused.
If someone was to consider using it, he would get nothing but a null-deref segfault.
I suppose the intent of a library is not to segfault if one of its arguments is used.
Therefore either the argument must be removed because it is considered useless (from the glooxwrapper library POV),
or the argument must be provided, because it is considered useful (from the glooxwrapper library POV).

At some later time (needs more refactoring), one may become able to support using the XmppClient with multiple rooms.
That could have a realistic use case for current 0ad, since there is the players chat room and the moderators chat room.
But the point of the diff is to implement on the XmppClient what gloox provides us and pass it on to JS, so that JS can decide what to do with that information (Instead of segfaulting on top of it)

Deduce the objective of the patch from the mentioned circumstances and verify that it implements that in the stated scope.
Triplecheck that there is no memory leak introduced, and verify with valgrind while finding other leaks.
Notice that there shouldn't be a leak, because no new pointer is introduced, and because setting m_Owned to true results in double-free.
Not ice that the performance impact should be verly low, since the wrapper class only stores two pointers and a boolean.
Notice that there are many unsupported features that would be better off being supported (visitor role, ban support are historic examples), so this is one of them and thus a good idea to implement.
Noice that it would be very inviting to add the "room": room.name() line to every CreateGUIMessage call.
Notice that displaying the roomname is pointless as long as there is only support for one room however.
Notice that adding the commented out property also is useless, hence UNUSED() being used properly (instead of semi-hiding the NULL).
Notice that we want a mutable reference to the room, so that one could call room.setNick("foobar"); or other mutable methods of the room.