Other question: some numeral systems simply do not have a way to represent some numbers (e.g., 0 in Roman numerals, or numbers greater than 50 in circled Arabic numerals). Should we change NumeralSystem::apply's return type to Option<EcoString> and let the user of Codex handle those cases?

This is clearly not something that is within the scope of this PR, but numeral systems could be merged with the concept of number formats, making apply accept an f64 and return some string when the numeral system is able to express the number.

I removed the dependency on ecow by using Display as you suggested. I did so without a NumeralSystemSpec enum because this felt unnecessary, especially because we do not expose the formatting functions.

I'm working on preventing allocations in positional and bijective.

I'm working on preventing allocations in positional and bijective.

std uses an array and writes into it in chunks starting from the end. This would need a bit of unsafe or a dependency on something like arrayvec, so maybe the vec is not so bad after all. (Edit: You don't even need MaybeUninit for this, just initialize an array of chars with '\0', so this can just be safe for a probably quite small performance cost.)
When keeping the Vec, I'd definitely use Vec::with_capacity(n.ilog2() / radix.ilog2() + 1) to make sure there are no reallocs.

I found a way to prevent allocation for non-bijective positional systems, but since I'm not at all used to reasoning with bijective positional systems, I'm not really sure how to to that for those, so I was also thinking of using with_capacity instead to at least make sure we limit the number of allocations to one.

The problem with using an array is that it has to be of a size known at compile time, meaning we have to assume the worst case, with is u64::MAX with a radix of 2. And this is clearly too much memory.

we have to assume the worse case

not necessarily, you could check against a pre-defined list of constant radixes.

I think allocating a vector with Vec::with_capacity is better. If we want to prevent allocations, let's do it using an algorithm that works all the time.

I did not add tests for every numeral system because I would like to go over them in separate PRs to make sure that they are all correctly implemented.