Created attachment 152221 [details] ODT file for experimentation Thin Spaces are not properly rendered in proportionally spaced fonts. It is my experience that the thin space should be about half the width of a space. This appears to be the case for mono-spaced fonts, but not for proportional-spaced fonts. Please see attached ODT and PDF files.
Created attachment 152222 [details] PDF of rendering example
IIUC fonts do specify metrics for the NPC and spacing and Harfbuzz will use exactly that spacing for layout. It is only when using fonts with no coverage of the NPC and space Unicode that either os fallback or spacing for an undefined glyph is assigned. We'd nned specifics of which font you are having issue with--and which Unicode spacing. Perhaps a sample document, save to one of the flat ODF document formats.
Liberation Sans and Liberation Serif has glyph for U+2009 and U+200A, so we use the widths provided by the font. Liberation Mono does not have glyphs for both characters (which is understandable, it is monowidth font), so the fallback mechanism in HarfBuzz kicks in and it calculates suitable widths for these spacing characters. This is working as intended, if you think the font is wrong you need to report this to the font developers (though since these particular fonts are meant to be metric-compatible with other Windows fonts, it is unlikely that they will be changed).
Created attachment 152231 [details] testDoc at 200% on Windows build of 6.2.4.2 The attachment 152221 [details] test doc opened on Windows 10 with 6.2.4.2 build. On this platform and build, the metrics for U+0020, U+2009, U+200A spaces are reflected on canvas. They match the spacing of the OPs PDF output (shows Mac OS X 10.12.6 Quartz PDFcontext). So, agree with Khaled that our HarfBuzz implementation on macOS is honoring the metrics provided by the font(s). And falls to the font designer to provide correct fonts. => NOB