@David-Healey Had Claude do a deep dive on this. My summary:
1. It was fixed in JUCE 8.
JUCE 8 (2024) introduced TypefaceMetricsKind with two modes: legacy (the old per-platform behaviour - explicitly documented as "metrics may differ for the same font file on different platforms") and portable (same metrics everywhere, based on the sTypo metrics - i.e. the same table family our harmonisation aligned everything to). portable is the default for the new FontOptions API. legacy survives only for the deprecated Font constructors. JUCE 9 (released three days ago) carries that forward. So the divergence we measured isn't just fixed upstream - it's acknowledged as a framework bug with a designed migration path.
2. Submitting a JUCE 6 to JUCE is a non-starter. It's 2 major versions EOL. Fixed in JUCE 8 anyway.
3. Would a fix even be accepted, considering it's technically the font at fault?
JUCE 8 is the counterargument to that. The JUCE team looked at this exact situation and concluded the framework should absorb it. And our own data supports that: Google-shipped fonts (multiple Barlows and Michroma) carry disagreeing tables. When the ecosystem's most mainstream font foundry ships "broken" metrics, they're not broken - the platform-divergent reading of them is.
4. Submit a fix to HISE
This would technically be a fix to the current JUCE_customized submodule repo and I don't really want to go there. It's a heavily customised version of JUCE 6 and sounds like at some point Christoph will move to JUCE 9 (judging by previous comments), possibly inheriting the fix anyway, so I wouldn't know where to start with this.
I'm happy to leave all this here with a note to @Christoph-Hart that if he wants to take this on I'm sure we would all appreciate it but it feels too messy/convoluted for me to take on right now.