Here's what I surmise is happening, in execution of Martin's original code.
TABPAGENO is unique: You can reference it as a verb object, but its value is (obviously) not determinable until formatting of the output pages is in motion. Ultimately, page-break points (and hence the page-number of a row in the matrix) may depend on conditional subhead and subfoot lines, which in turn depend on matrix columns, both the accumulated verb-object columns and the Computed columns in the matrix.
Space is allocated in the internal matrix for the TABPAGENO column, and for any COMPUTE columns that depend on it, and for their LAST values -- but they have to remain unevaluated (zero or blank) until the page-break calculation phase, after all other computes are evaluated.
The bug seems to be two-fold.
First, the Computes that depend on TABPAGENO (and/or LAST TABPAGENO) are being evaluated twice -- once (prematurely) along with "normal" computes, and again (deservedly) at page-formatting time -- such that the first evaluation polutes values used in the second evaluation.
Second, the pushdown of matrix columns into their LAST-value columns for "normal" columns (such as MODEL) is being done (prematurely) before the computes in the page-formatting phase.
As a result...
In the first evaluation of
NUM/I10 = IF MODEL NE LAST MODEL THEN 3 ELSE (IF TABPAGENO NE LAST TABPAGENO THEN NUM+11 ELSE NUM);
for the first row, LAST MODEL is blank, so MODEL and LAST MODEL are unequal, and NUM gets the value 3.
Then, in the second evaluation (after TABPAGENO is evaluated), MODEL and LAST MODEL are equal (both contain "V12XKE AUTO"), while TABPAGENO and LAST TABPAGENO are unequal, so NUM gets "NUM+11" which is 3+11=14. (QED)
- Jack Gross
WF through 8.1.05