A few years back I discovered that one technique for a font to do its own Indic rearrangement on HarfBuzz was to not declare lookups for the script, but to fall back to the 'DFLT' script. (I don't know how well it worked on Windows.) This worked provided one could find at least one normal feature that would be implemented for the characters. However, at least for Tai Tham, this stopped working (if it had ever worked) with the Windows shaper(s), because the Windows shaper would perform Indic shaping, and then the font's lookups would do Indic shaping on the outputs. This sometimes wrongly moves marks from one syllable to the previous syllable.
I started doing some tests with Windows Renderers on Noto Sans Tai Tham V2.000, expecting to see the problem. (I can't find a formal report on the issue against the font.) Using Windows 10 from March 2017 (an evaluation distribution for Edge), I found the problem, as expected, in Notepad and MS Edge. (MS Edge then used a Windows shaper.) However, when I tried it on a liver version of Windows 10 (patches might be being delayed for security checks), I found the problem in Character Map but not Windows or MS Word. (MS Edge now uses HarfBuzz for shaping.) Does Microsoft have a plan to progressively eliminate this problem from overhelpful renderers, or is it each application for itself? Has the overhelpfulness been suppressed in some less than obvious way? I am wondering whether I should at least register the issue against the font. The issue may affect some needed repairs to the DIY shaping - at first glance much of the trouble may be having lookups in the wrong order.