OK, seeing is believing.  

But I was convinced that there must be something "unusual" about the circumstances where this problem happens, because otherwise I would have expected a ton of tickets from customers (continued running table headers are, after all, very commonly used).

And especially since I went all the way back to the XPP 9.0.0 release to test the submitted sample and the problem still occurred, which meant it wasn't something that got "broken" along the way (at least not since then).

And there is something "unusual", or rather a combination of things making it unlikely for the problem to happen, but it's not something "obvious" that a user would be able to pick out.

I've now identified what the "scenario" is that's causing composition to do the wrong thing (and why this is not being seen "wholesale" by all customers).

1. The font setup has ligature replacements active.
2. There is only one word on the last line of the continued running header row.
3. The last word of the (to be a continued running header) table row is "form", which begins with 'f' which is the beginning of some of the RP (replacement spec) rules, so composition begins to process for a possible ligature replacement.
4. The maximum size of all the RP spec rule strings is greater than 4 characters, so the ligature replacement processing code buffers up characters past the full word "form" - and this is where things go wrong - it gets into the next line, which is no longer part of the running header row. Because of that the current logic then turns off that it is processing continued running header text and then the ligature buffer (which didn't match any RP rule) gets pushed back onto the input stack BUT is no longer marked as running header (i.e. generated) text. Then when that text gets re-processed again the "state" of that text is messed up.

I don't know if it's plausible as a workaround until a fix can be determined and a hotfix delivered (which might not take too long), but if you can (temporarily) turn off ligature replacements in the last cell of the "continued" row(s), or even the just the last word, then this problem will not happen.

To do that you would have to have a (or define a new) Font Variant spec FF/FV pair where the Lig/Accent Replace field is set to "none" and then set the FF and/or FV (e.g. with <ff> and/or <fv> macros) to that rule around the text in the last table row cell (or the last word of that last cell).

As "proof-of-concept" I tried that with the provided sample. The FF/FV being used was 0/1. I copied that rule in the Font Variant spec and changed the Font Variant field to 4 (an unused FV value for that Font Family) and the Lig/Accent Replace field to "none". Then back in the table (with fresh DIV contents), I changed that last word "form" to "<fv;4>form<fv;1>". When I composed, the problem did not occur.

Looks good -

I was able to test against JOB_xybase2 the issue no longer appears in the continued heading row when the table breaks to a second page. Steps taken (as Jon described above) in JOB_xybase2:

Open the FV spec and duplicate all font family 0 entries (I numbered the duplicate family "100")

In each rule for font family 100, change Lig/Accent Replace from 95 to none

Update the font used in the table to use font family 100 and compose

The last word in the last line of the continued header is now showing properly as generated:

Kai Chung Lew - let me know if this workaround addresses the issue in job you mentioned above. 

Looks good -

I was able to test against JOB_xybase2 the issue no longer appears in the continued heading row when the table breaks to a second page. Steps taken (as Jon described above) in JOB_xybase2:

Open the FV spec and duplicate all font family 0 entries (I numbered the duplicate family "100")

In each rule for font family 100, change Lig/Accent Replace from 95 to none

Update the font used in the table to use font family 100 and compose

The last word in the last line of the continued header is now showing properly as generated:

Kai Chung Lew - let me know if this workaround addresses the issue in job you mentioned above.