Glad that solved it.
A double tone? Having more than one tone mark would only be needed in minority languages, and in those cases one of the tone marks would be acting as a vowel, I think?
What I meant was, if you’re positioning an upstairs tone mark on saraI and its friends using anchors, why not do the same when the upstairs tone mark is sitting on a nikhahit?
I have to try that, but when I paste the strings I got from the client in Illustrator, the components used are those so I just implement those to get the expected result.
As I mentioned, I am a little lost (now better) around thai and their rules!
Thanks for all the help! I will keep posting if anything 
Feel free to post further questions here, or DM me if there’s anything I can do to help you feel less lost
I am wondering why if you don’t change some conf in Adobe apps, thai tone marks/vowels looks unaligned in apps like Pages/Adobe and in FontBook looks good (as designed). On the other side, on other fonts (like Tahoma) looks good in all contexts. 
This has to do with a tricky process called text layout and shaping. The instructions inside the font — telling it to substitute certain glyphs in certain contexts, or telling marks where to sit — need to be read by a shaping engine, so that the correct glyphs can be displayed in the correct places. I’m not the expert on text shaping engines, so maybe others will weight in here, but the key thing is that there are various sorts. Sometimes the shaping engine is built into your operating system: if you’re on a Mac, by default the font’s instructions will be interpreted by a different shaping engine than if you’re on Windows. And sometimes the shaping engine is built into the app you’re using: the Adobe apps, for example, historically used their own shaping engine so that text looks identical whether you’re using the Mac version or the Windows version. There are also differences between different versions of the same shaping engine (so Windows 8 can handle different scripts better than Windows 7) and between different implementations of the same shaping engine (so we see slightly different results sometimes between Firefox and Chrome, which both use an opensource shaping engine called Harfbuzz). Harfbuzz is now used by Adobe apps for the Southeast Asian scripts (but not other scripts, I think, yet), but the user has to enable it in the settings we talked about above. There’s no good reason they can’t enable Harfbuzz for all scripts by default without user interaction, and this is something I and others have spoken to them about.
Anyway, what all this means for font makers is that we have to test our fonts on as many platforms and apps as possible, and sometimes add extra OpenType code to help the font display nicely in all those different places. If you’re in the unfortunate position of trying to support pre-2012 systems, there may not be any way to get some scripts to render correctly.
Of course every environment (?) supports the Latin alphabet well enough already, and operating systems are nowadays catching up with the diversity of different scripts used around the world, though there are still many scripts that are yet to be encoded in Unicode and will take years to be implemented. When it comes to different apps, though, it really depends on how much the developers know about the different ways writing systems can work. Figma, for example, seems to have a very rudimentary grasp, conflating languages with scripts and simply bundling together everything as ‘non-English languages’ (If “non-Latin” is a bad term, for me this “non-English” borders on unethical).
So, basically, it just depends how intelligently each app can manage each script. I would not expect bad results in Pages, so if you can post a screenshot of what’s going wrong maybe we can figure out what else the font needs.