importing glyphs from some free fonts is not enough; some scripts need that you also borrow the OpenType features allowing their contextual selection (for now only the Arabic contextual forms are borrows, Indic scripts are ignored so you only get the isolated forms of their letters, e.g. in Devenagari or Myanmarese). The result is then incorrect.

The mandatory features should be obeyed, even if we can safely ignore optional features  such as variant forms, decorated forms (unless they are usually used in autonyms, but anyway even in HTML these optional features are not rendered unless you activate them specifically with specific CSS styles).

-- see the OpenType specs about which opentype feature is mandatory for each documented script; note that some scripts are still not documented, OpenType specifications are still a work in progress, even for scripts which are already encoded in Unicode, notably for the most recently added ones. For example the Myanmarese and Tibetan scripts require some mandatory features still not documented, but that have been tried by various font vendors with more or less success. Only the Arabic script is very precisely documented, not just informatively in OpenType, but normatively in the Unicode specifications for its contextual joining types, which become madatory features in the OpenType specs, and similar features in other font technologies like AAT, Graphite, or SVG fonts. --

Thanks for pointing where the fonts are developed.

I note that your Github repository contains a "languages.txt" file that you maintain yourself manually, when it should be generated from the wiki, using a Lua or PHP script enumerating all supported language codes (from the Site matrix, or from languages.php) and generating the list using te equivalent of {{#language:code}} in wiki syntax. This list may evolve over time when the Language Committee will add new wikis, or when it will decide to change the preferred language names.

Your list is completely unordered, and as it is long, it will be hard to see if it does not contain duplicates, or alternate names no longer supported, or typos. I suggest you sort this list by importing it in an Excel column to sort it in CLDR order (make sure you've selected the English language in your Excel document so that its CLDR collation tailoring will be correct and stable).

The other option is to prefix each line in languages.txt by the language code and a TAB or SPACE before the autonym, allowing to sort the file simply by language code. These language codes (using lowercase Badic latin letters a-z and the hyphen-minus) and TAB or SPACE will not pollute the list of characters to include into the Autonym font which already need these characters for the autonyms themselves (the only addition would be the TAB or SPACE separator and the newline characters which are already mapped in the font, so you  don't need specific character filters for these, when your script will generate the list of Unicode characters to map in the generated font).

For stability of the font (if there are several deployed versions of MediaWiki with different lists of languages supported by #language), you may want to add an additional "mul" language for adding additional characters to keep, or use a versioned line (such as "kk-x-1.2" containing the language autonym for Kazakh in version 1.2), so that the Autonym font for ULS will work on all wikis with different versions of their language support.

Note also that these generated language names may contain RLM/LRM marks (which you don't need to map to glyphs in the geenrated fonts, are they are to be supported only by the text renderers themselves; but if you map glyphs for these controls, they should be completely empty with a zero-width advance, or should be mapped to symbols for visible controls, but this is not a good thing to do for this Autonym font which is not intended to be used in text editors with a "visible controls" mode).