Here's the crux: because the proposal relies solely on generic
modifications of the xml info set (both structurally, by changing
the tree, and by modifying attributes), and all those operations are
considered valid (section 3, items 6 and 7 of the
generic-ct-proposal), the set of semantically distinct editing
operations *is unbounded*.
Which is a fundamental problem, for all applications that need to
map the change tracking markup into their internal,
optimized-for-editing document models - because what you have here,
is a limited set of editing operations, that are closely related to
concrete user actions ("insert" an object, "delete" an object,
"merge" two objects - with a very application-specific meaning, that
may not map 1:1 to the xml representation).
