CoreText doesn't, but no reason we shouldn't do.

Not used in any fonts.  Not well-specified when mixing kerning with
Cross-Stream positioning.

Tested with Waseem TTC:

$ hb-shape Waseem.ttc جحخج
[F1Jeem_R2=3@0,180+479|M1Khah_L2_R2=2@0,682+403|M1Hah_L2_R2=1@0,1184+403|I1Jeem_L2=0@0,1184+744]

Solves a mystery or two.  I'm fairly confident this is what CoreText does now.

Getting closer.  So many open questions still...

In a series of kerns in one action, kern all but last glyph forward,
and the last one backward.  Seems to better match what CoreText is doing.

Test cases, with GeezaPro Arabic:

$ ./hb-shape GeezaPro_10_10.ttc -u U+0631,U+0628
[u0628.beh=1+1415|u0631.reh=0@-202,0+700]

$ ./hb-shape GeezaPro_10_10.ttc -u U+0628,U+064F
[u064f.damma=0@0,-250+-250|u0628.beh=0@250,0+1665]

In a later change, I'll make kern machine avoid producing negative kerns.

Not sure why, but seems to better match GeezaPro Arabic w CoreText.

Quite possibly I'm doing something very wrong...

Still disabled.

Did this ever work?