GeezerVison

Most of these are 1-to-1 mappings of a block; I wonder if there is a more compact representation that could be used? Something like:

# (start, end, new_start)
# up digits
(0x30, 0x39, 0x30),
...
# bf latin lower case
(0x61, 0x7a, 0x1d41a),

maybe plus a small dictionary with some of the exceptions, depending on how they fit into the blocks.

The lookup table could be generated from those if necessary.

This is exactly the way I generated the lookup table, offline:

1. map the entire range
2. fix missing/moved codepoints based on a smaller lookup table

At some point I did consider writing special mapping functions but I figured that a lookup table might be preferable for performance.

Do you prefer to generate the lookup table (for example on module load) instead of hardcoding the entire table?

IIUC, math fonts should have tables with various layout metrics. We currently have those hard-coded in the various FontsConstantsBase subclasses, and they are likely incorrect for an arbitrary math font.

So this will likely need to parse this data out of the font and implement at least get_axis_height that was added in #31046, get_xheight maybe using #31050, and get_quad from #31110. But it is likely that you will want to refactor some of those remaining uses of the constants so that they fetch the information from the fonts as well.

I fully agree. Doing this may involve some refactoring though, because the FontsConstantsBase subclass could not be determined purely from fontname but would be dynamically populated based on the loaded OpenType font.

That said, I made some experiments locally. Unfortunately, Freetype does not parse the MATH table. We could use fonttools, which is a hard dependency anyway.
There are several open questions how to map the OpenType layout metrics to the legacy TeX-inspired variables used in mathtext. Does it make sense to postpone that to a separate PR and focus on the basics here?

While I would like it to happen, I'm not sure this will be ready for 3.11. So if we're aiming for 3.12, I think it's okay to spend some time getting everything worked out in separate PRs.

I think this will break the caching for MathTextParser._parse_cached, but I see it already doesn't really handle any of the other mathtext.* rcParams, so I guess that's something to work out at some point.

Typo or no such possibility? Probably could use a comment for the latter.

Bold italic digits are not defined in the Unicode standard. Actually, neither are regular italic digits (which I need to fix in the code).
In unicode-math, both are mapped to their upright variants.

This is related to a bigger open question. unicode-math maps \mathit (and \mathbf, \mathrm, \mathsf and \mathtt) to the corresponding non-mathematics fonts, which support all alphanumeric symbols and apply normal text kerning rules (and ligatures).
I have not defined such a mechanism here to keep it simple. Mapping mathrm is trivial. In principle one could load italic and bold versions with their corresponding options, too. Sans serif and typewriter would be a bigger stretch. I am not sure it is worth it, though.
Note that this only matters because we now have proper italic support in the other font classes.

I see two options:

1. simply map to their upright variants
2. implement loading the corresponding text fonts and try to apply unicode-math's logic

I would prefer option 1 and leave option 2 as a project for the future.