This is brittle. If we decide to modify createAddNewMembersMessageDatasFromDMOperation we have to remember to update this place, because we need to have different message IDs for different messages. We should address this brittleness by modifying createAddNewMembersMessageDatasFromDMOperation and similar functions in other specs to return a map from ID to message data. In notificationsCreationData we would simply omit the IDs.

At this point, this function doesn't process the operation, but instead, it creates the message data, which should be reflected in its name.

But I'm wondering whether we should change the approach. The problem with the current solution is that we duplicate a sequence of ifs between functions. We could avoid it, if this function returned not only the message data, but also a thread update (which can then be spread with threadInfoToUpdate in processChangeSettingsOperation).

Why do we have to accept a threadColor as a separate argument? It should be possible to generate its value from the operation.

This is brittle, like in add members spec, and some others - we should update all the places. Also, if we return only one message from createMessageDatasFromDMOperation, maybe we can return it instead of an array?