ThreeWayMerger

The real, end-to-end 3-way merge, combining Merger's attribute-level reconciliation with PcsMerger's structural one - each catches conflicts, and resolves edits, that the other cannot:

• Merger decides a matched node's own tag/attributes, attribute by attribute - so two sides changing different attributes of the same node (the running HelloWorld2A/HelloWorld2B example, MergerSpec) combine cleanly. It has no notion of position at all, so it is blind to reordering and reparenting.
• PcsMerger decides a node's position and parent - so a plain reorder or a Kaining 10-group-ungroup reparenting conflict, both invisible to Merger, are handled correctly (PcsMergerSpec). Its own Content relation, though, only ever sees a node's whole tag+attributes as one indivisible blob - by itself, it would (wrongly) report the HelloWorld2A/HelloWorld2B case above as a conflict, since it can't tell "different attributes changed" from "the same attribute changed differently".

This reconciles the two: structure (which nodes exist, in what order, under what parent) comes entirely from PcsMerger/PcsTreeBuilder; a matched node's own tag/attributes come from Merger wherever Merger has an opinion (i.e. the node has a Self) - PcsMerger's own (coarser) content resolution only fills in the rest: Self-less nodes (Properties, the PathGeometry chain, ...), which Merger never sees at all.