How about fonts that have been removed? Do you think their font test pages should be kept or purged (with an option?)?

Not fond of that, it will be useful to you and 2 other people, and you'll often regret not being able to compare new fonts to old fonts.
If really needed, have it available on long-press on that menu item so to not bug users with a useless thingie.
You could also have an option or prompt to put new fonts at start if there are new fonts.
And the code should not be duplicated that much as you did, it could be a parameter to the function to pick all or only new fonts.

New fonts in current session? Is that a thing we support?

New fonts met at koreader startup are (optionally?) marked "new" and (optionally?) shown first.
On next koreader restrat, they are no longer considered new.

Ah right, that way.

[poire-z] If really needed, have it available on long-press on that menu item so to not bug users with a useless thingie.

The idea was to have the menu entry only appear when new fonts were loaded in the given session, which I was asking for help with. Then the >99/100 times users have not installed any new fonts, the menu entry wouldn't be available and noone would be bothered by it. But I was having trouble setting up that condition. Is the table newly_added_fonts outside of the scope of the menu set-up function? If that was the issue, what would be the best way to access it? Via an intermediate function? Or making newly_added_fonts global where it is first defined? (Still curious from an educational perspective, although I will probably abandon this PR now.)

And the code should not be duplicated that much as you did, it could be a parameter to the function to pick all or only new fonts.

I was trying that route as well but found that the saving of relatively few lines of code was not worth the complication. Although it is likely I wasn't using the most efficient techniques.

But I was having trouble setting up that condition. Is the table newly_added_fonts outside of the scope of the menu set-up function? If that was the issue, what would be the best way to access it?

It's a module local variable (so, a kind of global variable inside the module), so it should be accessible from all the methods in readerfont.lua.
I think the problem is a ordering/timing problem: newly_added_fonts is only created later, after self:getFontSettingsTable() is called (both are called inside ReaderFont:setupFaceMenuTable(), but self:getFontSettingsTable() is called before self:sortFaceList(face_list) which build newly_added_fonts.
So, it would need some clever reordering/prebuilding, that I'd rather not think about :)
(The quick - but ugly as the building would not read naturally - solution could be to move this to later and use table.insert(self.face_table, 1, ...) to insert it at start:

I was trying that route as well but found that the saving of relatively few lines of code was not worth the complication. Although it is likely I wasn't using the most efficient techniques.

It would be bothering from a maintenance stand point, needing us, if we change one function, to not forget to update the second similar function.
The solution would just have been, in the clone (new menu item or hold_callback) of:

Then the >99/100 times users have not installed any new fonts

All in all, I think the simplest no-user-choice solution would be to keep that single menu item and function, and to create the sections for the newly fonts first, and later the old fonts. That way, you get them first when opening the sample epub - but you still can compare the text to the old fonts which are later in the book.
This can be the default behaviour or depending on the setting. It would just (dunno :)) need a copy/paste of:

Looking at the above, I thought this was already what is happening - the last snippet gets the fonts already sorted with newest first (if there are new fonts). But testing that, it looks like it's not the case.
Oh, it's just a matter of:

--- a/frontend/apps/reader/modules/readerfont.lua
+++ b/frontend/apps/reader/modules/readerfont.lua
@@ -888,4 +888,5 @@ a { color: black; }
 ]], _("Available fonts test document"), _("AVAILABLE FONTS")))
     local face_list = cre.getFontFaces()
+    face_list = self:sortFaceList(face_list)
     f:write("<div style='margin: 2em'>\n")
     for _, font_name in ipairs(face_list) do

(Adding some cosmectics like appending "new" in the toc or the titles is probably possible.)

@poire-z: Only the new fonts should be on top though, and everything else should still be in alphabetical order (not the recently selected order). So instead of just calling sortFaceList(face_list) I would copy your for-loop from 830-838 and append a " [NEW]" to each new font name (I tried the nerdfont icon but it didn't print correctly in the book):

So we'd get (starting from 888):

]], _("Available fonts test document"), _("AVAILABLE FONTS")))
    local face_list = cre.getFontFaces()
    if next(newly_added_fonts) then
        local move_idx = 1
        for i=1, #face_list do
            if newly_added_fonts[face_list[i]] then
				face_list[i] = face_list[i] .. " [NEW]" 
                table.insert(face_list, move_idx, table.remove(face_list, i))
                move_idx = move_idx + 1
            end
        end
    end

Questions:

1. Any objections?
2. Is it okay to duplicate this for-loop or should I make it into a function?

1. No objection, looks fine to me
2. It is ok, it is small (and you add "[NEW]", so it would make that function more clumsy with a param append_new_to_name :)) Just add a comment -- Sort alphabeticaly, with new fonts first (as done in sortFaceList())

Thanks. And are you okay with the proposed wording changes? (Remove "Would you like"; change "read" to "view" [edit: "open" works as well].)

I'm fine with your wording changes. Still to be validated by our Style & Consistency Officer @Frenzie :)
(We may have a few "Would you like..." elsewhere.)

No problem. There's no rush. And before I start updating the commits, I wanted to ask about something else I'd like to add (before you call it useless :) ) -- a 'Compact' version of the font test document, with just a short paragraph and no page breaks. I know one can replace the default one (and manually disable the page breaks), but I think it would be useful to have both. The current one that shows off everything the font has to offer, and a compact one to just quickly compare several fonts at once per screen page, e.g., using the lorem ipsum sample text with some bold and italics thrown in. It could be on long-press or an extra button on the confirmation dialog, so no extra menu entry. Thoughts? Yay or nay?

And one more thing; regarding the sorting of the font list in the menu: if the user selected to have recently selected fonts listed first, I think it would improve the UX if the current font would be listed first in the menu when the document is loaded. At the moment, the current font is often way back in the menu because it might have been a while ago when the font was selected last. And then when the user wants to select one of his top fonts, he first has to go back to page 1 in the menu list. So the idea would be that when a new CRE-doc is opened and the menu table is built, the currently selected font would be considered 'selected' at that moment and be moved to the top spot. Do you agree?

a compact one to just quickly compare several fonts at once per screen page, e.g., using the lorem ipsum sample text with some bold and italics thrown in. It could be on long-press or an extra button on the confirmation dialog, so no extra menu entry. Thoughts? Yay or nay?

Rather nay. It's shipping another sample file, and making it less obvious which one the user should edit, and adding uneeded complexity for an edge feature. I understand you (and me sometimes) can be bothered with the multiple pages (but it also shows how many line per pages, and if the last line fill the page), but depending on one's needs, it's as easy as replacing the one sample file.
If you need to switch between different sample files, you can easily user-patch ReaderFont:buildFontsTestDocument() and prepend another ConfirmBox question to chose the filename, and update FONT_TEST_USER_SAMPLE_PATH, before calling the orignal function.

if the user selected to have recently selected fonts listed first [...] So the idea would be that when a new CRE-doc is opened and the menu table is built, the currently selected font would be considered 'selected' at that moment and be moved to the top spot. Do you agree?

Seems logical and fine. (I'm not using this option, so I have no experience with the current behaviour, and won't be if you change it :))

Strings are fine by me, but the entire HTML document is duplicated twice? Can't that be refactored a bit more elegantly?

the entire HTML document is duplicated twice? Can't that be refactored a bit more elegantly?

I'll revert that all; we agreed on a different solution (no separate function; just the new fonts listed first when any were found in the current session).

@Frenzie Thanks, I will track down the whitespaces

@poire-z I'm afraid I need to ask for help with this:

when a new CRE-doc is opened and the menu table is built, the currently selected font would be considered 'selected' at that moment and be moved to the top spot

I tried many things but nothing seems to work. Ideally I'd like the current font move to the top position only when the Font menu is opened (and then the font list immediately refreshed); not when the document is opened. But either one is fine if there's a problem with the 'onMenuOpen' route.

What would be the best approach to achieve this, and at which stage?

Edit: I think I found the solution.

@Frenzie How did the base update get in here? Did I do something wrong? :/

Otherwise it wouldn't be in there, but I don't know what you did.

What's the status of this PR ?
Changes looks good to me, but current PR lags and would restore older version of base & luajit-launcher.
Dunno if/how you can resync it call if you are using github web. You may want to start again from a proper master.

I wanted to some more research on Git/Github before I do anything.
Would it perchance be possible for maintainers to only merge readerfont.lua and ignore the other files, or is it not?

You may want to start again from a proper master.

Would that entail a new PR or could this one be salvaged in that case?

Best to start a new PR from a fresh branch synced with our master, re-applying your changes over the current readerfont.lua (there's been 91c15d5 applied since you started this PR).