Currently, no variants can be set for polyglossia’s secondary languages.

I’d suggest that the variable polyglossia-otherlangs should have the fields .name and .variant, and multiple \setotherlanguage{} commands rather than one \setotherlanguages{} command should be used.

Accordingly, the default.latex template should contain:

$for(polyglossia-otherlangs)$
\setotherlanguage
$if(polyglossia-otherlangs.variant)$[variant=$polyglossia-otherlangs.variant$]$endif$
{$polyglossia-otherlangs.name$}
$endfor$

Alternative: .options fields

Use polyglossia-mainlang and polyglossia-otherlangs variables, both having .name and .options fields, where .options can have a value of variant=…, e.g., variant=british.

An .options field would make it easier to deal with other polyglossia options, too, e.g.,

ar-TN => \setotherlanguage[locale=tunisia]{arabic}

de-AT-1901 => \setotherlanguage[variant=austrian, spelling=old]{german}

Agreed, the otherlangs variable didn't get the proper treatment in the language -> lang change. But then why not make it consistent (@nickbart1980's alternative), in YAML:

babel-lang: arabic
polyglossia-lang:
  name: arabic
  variant: whatever
  locale: tunisia
polyglossia-otherlangs:
  - name: german
    variant: austrian
  - name: chinese
    variant: ""

This makes the polyglossia-lang variable a bit more complex (it's a dictionary now) but offers more flexibility.

… or simpler, since most likely we’ll never be needing the individual components:

babel-lang: arabic
polyglossia-lang:
  name: arabic
  options: variant=whatever, locale=tunisia
polyglossia-otherlangs:
  - name: german
    options: variant=austrian
  - name: chinese
    options: variant=whatever

I'm not sure it's simpler since it's basically JSON objects under the hood anyway (so it doesn't matter whether you have two or three keys in the hashmap). But it's more complicated in the template polyglossia-lang.options.variant vs oplyglossia-lang.variant.

Well, no, I was thinking of storing the whole polyglossia “options” string, as used in \setotherlanguage[⟨options⟩]{⟨lang⟩} and other commands, e.g. \setotherlanguage[variant=whatever,locale=tunisia]{arabic} in the pandoc variables polyglossia-lang.options and polyglossia-otherlangs.XXX.options. But … whatever works …

Ah, I see. Indeed, that makes things simpler—as long as we don't have too many combinations of language/locale/variant etc. to generate, but that's not the case for now. I implemented it like that.