Don't forget to add a test in tests/suite/model/numbering.typ and to update the counting symbols in the documentation here:

Since all the languages which use the cyrillic alphabet use the same first character (U430) for their numbering system, there needs to be some way to distinguish between the language.

This could potentially be a significant problem, especially considering the current circumstances of the world. In particular, this may be quite uncomfortable for Ukrainian users, as well as speakers of other languages using the Cyrillic alphabet.

This is also related (but evidently much worse) to how all the "A"-like letters (latin A, greek Alpha, cyrillic A) look the same, despite being distinct characters. Even though this was already kind of accepted with the Greek alphabet, this particular case will require a much more careful decision.

FWIW I still think that some alternative format such as {Upper} or {lower}, e.g. {Russian/russian}, {Ukrainian/ukrainian}..., could be ideal.

Considering that the numberingx package implements precisely this, I'd be in favor of avoiding adding Cyrillic alphabet numbering until a more robust decision is made, one that makes it possible to unambiguously specify your desired alphabet.

I don't think a good solution/implementation is out of reach although you raise some good points which I didn't fully consider.

Perhaps giving a warning if one of the 'multi-valued' characters is used as the key for numbering without a language having been set in the document. Then for each of the 38 languages with translations in typst currently, we can provide, or point to the relevant alphabet.

Do you think this is a robust enough solution or are you looking for something more?

Perhaps giving a warning if one of the 'multi-valued' characters is used as the key for numbering without a language having been set in the document.

If we emit a warning, we still need to pick a default.

FWIW I still think that some alternative format such as {Upper} or {lower}, e.g. {Russian/russian}, {Ukrainian/ukrainian}..., could be ideal.

I'm on board with adding an additional more verbose format, see my comment here for the concrete design I'm envisioning: #1177 (comment)

I think we should, as a first step, implement these more verbose formats for the existing numbering formats. Once that works

• we can add implement the ambigious cases by providing solely the verbose format, not the short one
• explore whether contextually language-aware numberings would work out well

I'd like to take one step at a time and, for the reasons discussed above, consider the first part a blocker for adding Cyrillic, so I'll close this for the time being. Thanks still!

Okay - that makes sense. I will have a go at implementing what you mentioned. Did I go about this process in the wrong way? Would it have been better if I started a new issue to discuss this before opening a PR?

For smaller stuff a PR is typically a fine. For larger stuff, having some discussion on Discord or here first is better. This one wasn't really large, it just happened to be more intricate than it looks at first glance, so it's all good.