the reason why their Domain is [0;1] is because those curves are Reparametrized here:
but if you check the last value {1:22} you will see the domain is off of those bounds:
and that happens because last Curve at index 22 goes through Flip Curve, and its Domain gets inverted:
so by applying a second Reparametrize also for her you solve the issue:
the reason why their values are 0.111 and 0.889 is your slider for t set to 0.111 
you get as results t and 1-t, you need to move the Subtraction component a bit down to see the double connection here:
the component receives a single list of 23 items on one input, and two branches (two lists) with a single item each in the other: when two Lists have different length, the basic behavior of data matching is to duplicate the last element of the shorter List until that List has enough elements to match the longer one
the thought GH does is like in 2 steps: first it matches the number of Lists, then it matches the number of items
so first step of the CCX component: on A you have one list (of 23 elements) and on B you have 2 lists (with 1 element each)
- it duplicates the List in A in such a way it has 2 Lists (of 23 elements) in A, as many Lists as in B
- now that both inputs have the same amount of lists, it takes the first List of A and the first List in B: the first list in A has 23 elements and the first list in B has one single element → it duplicates the last (and only) element in the List of B until it reaches length 23 identical elements
- not it pairs first element with first element, second with second… and so on until the 23rd element
of course the element in B is always the very same element duplicated
so you get a data structure -in this case- like {path_of_curve_in_B : index_of_curve_in_A} which is actually very useful:
in this particular case each curve of A has an intersection with all curves in B, so you get 23*2=46 intersections
but what if just a few curves out of 23 were intersecting something?
if you didn’t have a data-structure like that, which tells you which curve in A is intersecting which curve in B, then you would just know the final result, but you wouldn’t know which exact pair of curves originated that intersection event
so that sort-of “automatic grafting” allows you to backtrack the origin of the intersection, because in case they don’t intersect they will leave behind an empty branch (and by reading that branch patch you know which pair does not intersect), and same thing if they have multiple intersections you will get a path with many items inside
yes, and also one another important point: data-tree paths are more for us, than for GH 
GH uses lists, and matches those, but -generally speaking- is not really into the real “numbers” that compose a tree path like {0:13:5:4:2:0:0:0} that is just the “street address” of a List, which gets usually ignored
this means that if you want to match two data-trees, you need yourself to make in such a way their branches are matching, and as long as they do you are going to be fine
so for instance this is going to be OK:
but also this (where path are renumbered) is going to be OK:
and this
so the best advice is to not try to clean too much your tree/paths unless they are too difficult to be interpreted (by you)
there is a very nice lesson on Data Trees by Andrew Heumann which I believe also touches this topic:
