#4114 font substitution using lastSubstFont leads to font "latching"
r25342 and r25343 introduce Chunk.lastSubstFont as an optimisation for font substitution lookups. If you wanted to find any font that works for you, that would be OK, but jEdit allows a sequence of fallbacks, and that sequence is no longer respected, yielding unpredictable results.
Consider you have a default font set to fontA, and two fallback fonts fontB and fontC specified in that order in the Text Area properties under "Additional fonts with font substitiution".
Create a file where the first symbol will be something that is in fontC only. Add more symbols which are both in fontB and fontC. These symbols are still displayed with fontC! This will not change until you hit a symbol which isn't in fontC, and if you have "search all system fonts" enabled who even knows what will happen!
As far as I understand it, the philosophy of a fallback sequence is "I like fontA and want to use it in general. If that fails (e.g. math symbols), there's fontB so please use that. For strange stuff, use fontC as a catch-all (e.g. DejaVu Sans has a lot of symbols), and then if you fail that, just find any way you can display it".
I think this change should be reverted, unless it is the stance of the jEdit developers that you don't care which font is used, so long as something is displayed.
Commenting out the following lines in public static Font getSubstFont(int codepoint) makes the issue go away:
if (lastSubstFont != null && lastSubstFont.canDisplay(codepoint))
return lastSubstFont;
