Merges between two profiles of the same person can be rather complex.
In the simplest case, all the locations, dates, relations, and names are identical or effectively equivalent. When the merge is unambiguous like this, it should be almost entirely automatic.
The more common cases, there is data missing between merges but matches on other points; it is ambiguous as to whether the profiles match in a strict sense as in the simplest case, but if the profiles aren't contradictory to each other and they're complementary with intersections then it should be almost entirely automatic again though with more human supervision in the decision making process. These are nice cases because they allow a profile to be constructed from incomplete pieces.
Also somewhat common are imperfect matches. There's complementary information and equivalent information, but you have some entries which are contradictory to each other. One profile says born 1800 and another says born 1778, but they otherwise agree on everything else or almost everything else. These cases probably should be merged, but the contradicting information of both profiles should probably be purged; contradicting information can be positively identified as being something in need of further research. If deleting the contradicting information from both profiles renders the merge ambiguous then we enter into an unhappy case where merging should not proceed, see below. However, most times this case can result in a sound merger provided that the majority of information is in agreement.
The unhappy cases are the ones in which it is ambiguous as to what the case is. Like merges between profiles which are totally complementary; what I mean by complementary is that they are each missing data that the other has; complementary with intersections in the above case means they're missing parts but they have parts (plural!) which are equivalent, so they are semi or quasi definite. But purely complementary profiles are wholly ambiguous, and even if one or two properties are shared it is probably not enough to disambiguate them. Consider Sarah Smith (Smith-1) and Sarah Smith (Smith-2) where Smith-1 has parents but no spouse or children and Smith-2 has a spouse and children but no parents; it is possible that they're the same profile, but it is more likely that they are not the same Sarah Smith eitherway more information is needed. The profiles should not be merged in this condition.
Then there are the dread case of the unconnected, anonymous, unknown last name at birth profiles. These are by themselves more trouble than they are worth. Sometimes they can be matched up in some systems with named and related profiles to fill in details, but the less information defined, the less likely that is going to be the case. A floating date of birth with nothing else is pretty much wasted resources.
Okay, all that is rough enough, but we're only talking about comparing two profiles to be merged. What happens when you have four or more profiles which have parts suggesting they are all the same profile but their merger depends on the merger of their relations. Example and case study: Motheral-2, Motheral-17, Motheral-25, Motheral-42, and Motheral-45.
At current, there isn't a way to setup what is functionally equivalent to a system of equations to check to see whether or not a branching merger will result in a consistent, inconsistent, or undetermined genealogy. There isn't a system in place to warn users that they may be merging from ambiguous conditions or that they might be creating ambiguous conditions by the merger. And eyeballing it takes some effort when you're comparing up to n-profiles and their relations; the commenting system would be how I would keep track of the complexities of such mergers, but I am finding that the spam protect locks me out (don't remove this) pretty quickly.
There's got to be a better way to deal with snarls like this. Especially if we are to get a handle on the accuracy and precision of WikiTree's profiles. Done right, the merger system could be a powerful tool for determining what profiles have incorrect information or need further research to further complete the tree. At current, I would hazard to guess that the merger system is similar to the GEDCOM import system in that it creates more liabilities than it resolves.