After some more digging:

• I published ex_cldr version 2.31.0 which includes a new function Cldr.Locale.script_from_locale/1 to return the script. For example :Latn or :Thai or :Deva.
• You can use the function Cldr.Validity.known(:scripts) to get the name of all the 167 scripts known to CLDR. This function parses data so its only used at compile-time in ex_cldr to build functions. Its not public API so use at your own risk (its not going away however). Cldr.Locale.language_data/0 returns a lot of data that can be used to map between languages, scripts and territories its more complex data but more complete.
• Google Fonts is really sloppy in its terminology using “charset” interchangeably with “subset” when it really means “script”. And it uses “language” when it means “script” too. Disappointing really since Google is the largest sponsor of CLDR.
• CLDR does have mappings from language to script so a lookup is possible and I’ll add a function to ex_cldr to make that easy. But there’s another problem needs solving first …
• The language names used in Google Fonts are not canonical and have no alignment with ISO 639 language codes making it difficult to map from locale.script or local.language to the right font “subset”.

Hopefully this gives you something to go on. Its an interesting and useful objective to deliver a typeface to a user that can represent the requested script. So I’m happy to help on the ex_cldr - just reply here or open an issue on GitHub.

Maybe you’ll find my text library useful? It has a native Elixir implementation of text detection. You need to install also the text_corpus_udhr library to have a corpus to work with for detection:

iex> Text.detect """
Договоренность о разблокировке украинских портов для возобновления экспорта зерна остается труднодостижимой, потому что Москва использует переговоры для реализации своих военных целей и обеспечения доминирования в Черном море, заявил заместитель министра экономики и торговый представитель Украины Тарас Качка.
"""
{:ok, "ru"}

It is possible to load (subsets of) a webfont dynamically in CSS by Unicode range, assuming that ranges for languages don’t change frequently:

Quote from the page:

For example, a site with many localizations could provide separate font resources for English, Greek and Japanese. For users viewing the English version of a page, the font resources for Greek and Japanese fonts wouldn’t need to be downloaded, saving bandwidth.

I suspect it won’t be that straightforward, awesome library btw!
I tried to find out the length if I had to put all the ranges in CSS, and it is arguably okay (especially with gzip/brotli) if the script isn’t common or arabic.

[
  common: 2363,
  arabic: 781,
  ethiopic: 474,
  latin: 471,
  greek: 450,
  inherited: 385,
  han: 276,
  grantha: 223,
  tamil: 204,
  hangul: 180,
  katakana: 179,
  ...
]

So mapping a language code to the right scripts to the right code points is not a trivial exercise.

Indeed. However, unless OP is creating their own font subsets, it is not necessary to check the relationship between scripts and codepoints (Noto variants did that for us), and the list of glyphs available in each font file can be used instead to generate the list of codepoint ranges, which I imagine could be automated with a FontForge script. Then I remembered where I first see this CSS attribute: Google Fonts. The CSS files they provide already have codepoint ranges for the fonts they offer:

• Noto Sans JP: https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap
• Noto Sans Arabic: https://fonts.googleapis.com/css2?family=Noto+Sans+Arabic&display=swap
• Noto Sans HK: https://fonts.googleapis.com/css2?family=Noto+Sans+HK&display=swap

Oh, that seems straight forward indeed. Just need a mapping from the ISO 639 language and/or ISO 4217 territory code to the Google Fonts language and it seems good to go!

Was a fun excursion!