I thought some of the discussion during Behdad's YouTube statement 'Font Wars 2.0: The Untold Story' was worth capturing. I have added additional information.
It was stated by Adam Twardoch that both rvrn and ccmp are supposed to be "on by default" and processed "early", before script shaping.
It was then pointed out that ccmp processing is disabled by default for the default script in pre-HarfBuzz MS Edge, which messes up fonts that use it to achieve some fundamental shaping, so that they work as well as the font permits. There is a Tai Tham example available at
http://wrdingham.co.uk/lanna/renderer_test.htm, with the font "A Tai Tham KH". Select the font to see the examples. (I think modern IE also shows the same pre-HarfBuzz behaviour.) It should be noted that the non-application of ccmp pertains to 'non-standard scripts'; standard scripts may behave differently. Please note that this font has since been updated beyond what is displayed on the site and that the font was targeted on Tai Khün, and apparently not on Northern Thai or Pali. It has some pleasing clever behaviour that depends on
Tai Khün spelling rules for its implementation.
Adam Twardoch further noted that executing
"ccmp" is essential to some functionality later on in the font (like
contextual alternates) but if ccmp is not executed, the rest of the
shaping does not work. ccmp
was intended as "after Unicode-to-simple Glyphs cmap resolution, do
some 'splitting' and 'joining' so that a different run of glyphs can go
into further features". There was a "promise" (intention) that
ccmp would be on by default. But seems old Edge turned it off for speed
reasons, like Chrome not rendering SVG
— so there was no reliable
"early, on by default" feature and thus rvrn was that
ccmp would be on by default. But seems old Edge turned it off for speed
reasons, like Chrome not rendering SVG
— so there was no reliable
"early, on by default" feature and thus rvrn was added.
When ccmp is disabled by default, so also are liga and calt. However, the fonts that use cmp for basic shaping usually don't make use of downstream substitution features. These font are generally written on the principle, 'Give me access to a substitution feature, and I will define the shaping.'
Comments
The problem with rvrn is how it has been communicated to type designers and the incorrect impression that some people have that variations-specific substitutions must go in the rvrn feature. Variations-specific lookups can go into any feature. Of course, tracking GSUB output and input across a complex multi-dimensional design space can get really complicated pretty quickly, and an argument can be made for doing as much as possible either as early as possible or as late as possible.
Look for "hb_ot_shape_collect_features" in this file; that is the general-purpose shaping engine and the features that it processes, in order (with pauses between blocks). Then between the magic "HARF" and "BUZZ" features you have the complex-shaper-specific processing. For e.g. USE, you look for "collect_features_use" in the USE shaper implementation.
At any rate, you can easily confirm that the general-purpose shaping engine runs rvrn before anything else, in all cases.
If an implementation is trying to make perf enhancements that avoid shaping, I would expect any combining mark in a string to kick into a shaping path.
Windows 7 certainly did not support Tai Tham. I can't speak to Windows 10: it would be implemented by USE, which I never worked on.
Where are you quoting that statement from? I don't recall ever using the phrase 'deterministic regular expression', and I'm not sure what it means.
Universal Shaping Engine ". The phrase which you used was, "which uses subjoined consonants in ways that may compress multiple syllables into a single cluster, causing recursion in cluster analysis". Iteration, of course, already occurs, so there's actually no reason for a problem given there.