I see what you mean now, and I agree. Sorry, I'd misread your question and was looking only at the n=... numbers shown in column 1 within the table and comparing those not to the numbers in the table caption but rather to their corresponding numbers for upstream links in the Directional Summary tables.
I'll look further into that. Right now, it looks like a bug, and if confirmed, I'll fix it.
Regarding why the software includes a trip for in the directional summary only if it passes through the first intersection, the short answer is that the table, as it's designed, can be either consistent or complete. I decided that consistency was more important. Making it complete both complicated and confused the meaning of the "cumulative" columns, and I thought it too misleading when grouping the two different types of columns together in a single table.
The policy, as you know, is that the Summary page of the TT&D report summarizes only those trip log runs that participate in calculating the various "cumulative" columns (e.g., CTT). This rule applies even though some of the runs thereby excluded should, at first blush, at least be included in the various link-specific columns (e.g., TT).
When trip logs enter the artery downstream from the first intersection, to be complete, and include those in the rows for downstream links, would either confuse the meaning of the n=... number in column 1 or require two n=... values, one for the link-specific columns and another for the cumulative columns. That is, these runs would apply to the link-specific calculation (average TT), but not to the cumulative calculation (average CTT). With the rule stated above, it's all or nothing. If the trip log is excluded from the cumulative calculation, then it's also excluded from even the link-specific calculation. Can't participate in CTT, so disqualified from TT.
With the way the TT&D report shows the n value (n=2 or n=3) just once for all columns, I decided it would be confusing or explicitly misleading to use a different set of trip log runs for calculating the cumulative columns vs. the link-specific columns. This seemed worse to me than being implicitly misleading, which is to use the rather arbitrary "consistency rule" that the link-specific columns and the cumulative columns shall both summarize the same set of trip log runs. At least this way, the user has some control (by generating TT&D reports for selected subsections of the artery) over what runs get included in both.
The other ("completeness") way, the user could use subsections to choose only those trip log included in the cumulative columns, the link-specific columns would unconditionally summarize all trip log runs, independent of the selected subsection, and the header column for each row in the summary report would need to show two values for n, one value for the cumulative columns and another for the link-specific ones. At the time, at least, this seemed to present more confusion than just enforcing a consistency rule, however unnecessary.
I'm open to revisiting this policy, if you want to suggest a better design or argue that it'd be worth whatever trade-off in order to get complete (if inconsistent) summaries when possible.