New MUC channels' group flags are initialized as follows:

  /* set initial group flags */
  tp_group_mixin_change_flags (obj,
      TP_CHANNEL_GROUP_FLAG_PROPERTIES |
      TP_CHANNEL_GROUP_FLAG_CHANNEL_SPECIFIC_HANDLES |
      TP_CHANNEL_GROUP_FLAG_HANDLE_OWNERS_NOT_AVAILABLE |
      TP_CHANNEL_GROUP_FLAG_CAN_ADD,
      0);

Then, when requesting a MUC, we have:

      /* deny adding */
      tp_group_mixin_change_flags (obj, 0, TP_CHANNEL_GROUP_FLAG_CAN_ADD);

I believe that when you are invited to a MUC, you should be in local pending and thus CanAdd should not be set until you move to members, but this does not seem to be the case.  Regardless, it is misleading to initially set CanAdd and immediately remove it on requested channels.

tests/twisted/muc/test-muc.py is buggy in a related way: it expects a GroupFlagsChanged signal with removed=0.  It just so happens that it catches the first signal and not the second, so the assertion succeeds, but the assertion is incorrect: until the conference server has allowed you into the MUC, you should not be able to add new members.