Here is a sketch of a plan, following discussion at #11223.

The problem: typst can accept an array for fonts. The fonts are tried in the order listed until one is found that contains a glyph. It would be good to allow this for font, mathfont, codefont in our template. But it would also be good to align the font fallback mechanism with what can be done in other formats, e.g. HTML (through CSS) and ConTeXt and LaTeX (at least with lualatex). Currently we have mainfontfallback, mathfontfallback, codefontfallback, sansfontfallback, but for lualatex these require a lualatex specific syntax.

Suggestion:

• Allow arrays across the board for fonts. In formats that don't allow fallbacks, just use the first one. Continue to support mainfontfallback etc. for lualatex, but deprecate these.
• Allow options to be specified for fonts, in the following way

mainfont:
  - EB Garamond
  - Noto Serif Bengali:
      script: ben2
      covers: latin-in-cjk
  - Noto Color Emojis:
      mode: harf

What to do if someone writes:

mainfont:
  EB Garamond:
    covers: latin-in-cjk

Treat this as a one-element array.

Or:

mainfont:
- EB Garamond:
    covers: latin-in-cjk
  Noto Color Emojis:
    mode: harf

Perhaps treat this as an array, though the order of elements is non-deterministic.
Perhaps emit a warning.

Affected templates
styles.html
font-settings.latex
default.typst
default.context

A thought: allowing the fonts to be objects with fields specifying options is elegant for the user, but it does considerably complicate things with the templates. Perhaps we could have the writers convert things to a consistent and simpler format .