Intersector behaving really strange

Intersector seems to Merge Attributes OK when I send 2 Creator Colinear lines to it in a test Workspace.

One scenario this could happen is if the Attribute Name in A is the same Attribute Name in C. Then the Clipper being an intermediate transformer changes the order in which features enter the Intersector transformer by letting A go first, and C go second. The first features in will get the Attribute Value where the Attribute Name is the same, so with a routing through the Clipper A goes in first, then C. Without the Clipper, it sounds like C is going in first and then A, so if the Attribute Name is A is the same as in C, then the original values in C will just be the output Attribute value for Collinear segments since they can be the first set of features in.

If this is the case, use an AttributeRenamer first on one of the common Attribute Names to make them different, or instead in the Intersector output the Attribute Accumulation to a List, and then use AttributeCreator to assign ListName{0}.AttributeName to the Attribute you are trying to update, so long as there is only one collinear intersection, otherwise you might need extra prioritisation logic around a ListExploder.

Additionally, you might find LineOnLineOverlayer better, depending on your data.

You could put both A and C into a Sorter first, and then into an Intersector using something from A that makes its Features come out of the Sorter first. However, depending on your data you may get some artefacts in cases where any A features are colinear with other features from A, or similarly if any features from C are colinear with any other features from C or more than 1 C feature was colinear with a feature from A. Otherwise, if you don't want to keep the Attribute values from C at all, and only interested in A's values then you could just use AttributeRemover on C first.

Noting though, LineOnLineOverlayer with Attribute Accumulation to a List is probably going to be the most reliable way of any general case of combining attributes from any 2 sets of colinear Line Features unless you were very confident there were not multiple colinearity intersections possible with conflicting attribute values that could accidentally have 1 attribute value take precedence over another.

In LineOnLineOverlayer, the number of colinearities can be determined by the Overlap Count Attribute, and you can tell if any of the output lines originated from C, and if there were any overlaps from A, and what their overriding attribute value is, by using things like ListSearcher, ListHistogrammer or ListExploder to examine the resulting list that has the original Attributes and values stored in it.