[Spliff]

THIRD

"Increasing the max supported is not a bad idea, although 32 would be a lot, and it seems as though what you're really after is an importance attribute that would alter the behavior of each flag value. There already is a Priority attribute defined -- I'm thinking a better way to approach this would be to leverage that (or possibly a new Importance attribute), something like:
Be able to configure some properties for each Priority value, via a new dialog, similar to the Flag/Flag properties dialogs
1) Font styling (i.e., bold, italic, underline, etc.)
2) Background color override
3) Label used in submenus
Then add a submenu and keyboard shortcuts, again similar to Flag, to set the Priority item attribute value.
The Priority would then be used in conjunction with the Flag attribute to format the item's font style and background."

It is my conviction that in almost every aspect - perhaps with the exception of 7) above -, the number, be it 7 or 20, 32 or 40 ("good heavens!", I hear you now!), will not make any difference, code-wise, since those lists, of 7, or "n", elements, would be contained in arrays, and you would have to adjust the respective dimensions indeed.

The code integration (i.e. adaptive Favorites code re-use upon Flags) described in the second part of 5) above would indeed cost some hours, but there again, the number, be it 12, 20 or 32, should not make any difference.

BUT you are perfectly right: Whilst "just 6" for categorization are way too few (#7 is "Done", i.e. a "ToDo", which is another "dimension" altogether), perhaps 12, 14 would be the ideal number for categorization in one dimension, or in several, similar dimensions, not 32 or more - we're perfectly d'accord here.

But by analyzing "how you do it", currently, i.e. how you have organized, in code, and in table(s), your categorization-plus-ToDo-by-flag, it seemed, and seems, to me that to also technically, i.e. code-wise, separate the different dimensions, would need quite some new code to be written, whilst just - and then sufficiently though - enlarging the number of the current flags would enable the USER to introduce different dimensions into their (code-wise, one-dimensional) system, hence hues, and even (since that alone would not be sufficient) leading special characters - which, unfortunately, can then NOT being searched alone for, so no "filtering" for them would be possible (single > or ! or similar are not "searchable" with your current FTS, but that could be implemented after all since it seems that for SQLite fts, it's the developer who has to do lots of work on their side, so they also have quite some means of influencing the "results"...).

As for "2) Background color override", let's face it: Background coloring-per-line is awful as hell; it's possible in UR (as well as in "Scrivener", e.g.), but it's so ultimately aggressive that no user will bear such formatting for long, and not even speaking of several such background colors -

But I understand what you mean by "override": Some OTHER command, overriding the regular, current flag setting, ditto your "1) Font styling (i.e., bold, italic, underline, etc.)", and for the dimension of (different) ToDo's and the like, that would have been, or would be, an IDEAL solution; it would not nessarily override a flag setting, but it would be combined with a (insofar sparser) flag setting, i.e. the flag would not (have) include(d) the formatting, too, but just the color(ing) (and perhaps a possible background color, different from the default background color).

Now my VUE example above was on purpose, since in there, lots of hues (i.e. shades of the same base color) are immediately available (functionally though, VUE is quite inferior, since there is no filtering by color, let alone by combinations, etc.), and so, it's easy to implement "degrees", but here again, "shading" can represent just ONE dimension, not two, and thus it either represents importance (and the like = "weight" of a factor), OR urgency (and the like, but e.g. "desirability" of a factor even might be different from its urgency, so we would have to cope with THREE dimensions here, not just two, whilst the color's hue just represents ONE).

Thus, even special background color (but in "decent tones", instead of crying yellow and the like) would sometimes be needed, in order to represent a dimension not to be mixed up with the one which would be represented by the hue, and the same, i.e. both remarks, are true for underlining - it's awful, but sometime it would be needed, but then not for importance, since that would imply that it would have to be deployed much too often... and so on: it's really a problem to do it all right and straight, and without (!) creating yourself a work environment asking you to leave by becoming visually unbearable.

Now it's clear as day that the ideal solution would be to have "enough base (text) colors", then another "switch" = command for hues (the same, in degrees, to then be applied to different colors), a third switch for bolding, a fourth switch for italic, and even a fifth switch for underline, and a sixth switch for background; underline and background would be rarely used but would then be of help, all of the switches would be independent of each other, and color and background color would not really be switches but palettes, since they would comprise several colors, and the "hue" "switch" would also be a range of 3 or 5 switches in some range, the middle = "no effect", and the outer settings to intensify, or then to "lighten" the base color upon which it is / those settings are applied.

Obviously, this seems to create chaos, but then, 20 or so years ago, you unfortunately made a design mistake: you combined bolding, italicising and underlining with the font / flag / color, and albeit I understand that in print, etc., "bold" and "italics" are different font, on screen, lots of programs "do it simple", and allow the application for all three, ^b, ^i and ^u upon tree elements - perhaps, partly, then selecting different fonts "behind the scenes", or just manipulating the rendering - btw, your speed considerations 7) above might become pertinent indeed if the user, with 32 flags, uses 15, 20 different fonts, but hopefully not so much when users just use the same font, then also in bold and italics (and perhaps in bold-italics which would make a fourth font, technically, indeed, but not dozens of them).

Thus, in order to COMBINE formatting (bolding, italicing, underlining, also in combination in case: remind yourself: that's already 5 "formats" here) with color(ing), in today's UR flag system we need 4 flags (instead of just do ^b e.g., to some vanilla, or then flagged, item), for in fact just one and only font, in default black, and if we then also want the font in just one grey tone, AND we want to apply different ToDo's to it, we're at 10, for blue at 15, for red at 20, for orange at 25, for green at 30... and if we then want scarlet, also, for "risks", "dangers", even 32 flags would NOT be sufficient if we insist to make available all 4 ToDo's (remember, we also have the vanilla, "regular" font, for "no action needed") upon our different categories...

In other words, I arrived at the the number of 32 by 2x2x2... of course, but also since I think that at least for the "main categories" (= base colors, "7" being a good number here ;-) ), and then for some "derived categories" (i.e. "tinted colors"), we'd need at least the most important ToDo's... and then, 32 flags are just "sufficient, if you plan well that is"... oh yeah!

I suppose that if you want to get out the font formattings (bold, italics, underline, NOT speaking of the special, little formats up/down not needed here of course, and instead of strikeout, I use grey, well: strikeout might multiply the needs again for some users then...) out of the flags, leaving just the colors (incl. the to flags, you would have an immense work to do - but I might be mistaken here? -, but it's obvious that IF you could do that, some 12, 16 colors (incl. the tinted ones) would be sufficient, and be more convenient than the current system... but then, is it worthwhile, supposed it'd be LOTS of work, of rehaul of core parts of UR? Possibly not!

On the other hand, given that you already have a good code base for a big enhancement of the current flag system, JUST by "updating" the flags number, and by applying Favorites code to Flags, including user's possibility to re-order, i.e. to SORT their flags into groups (blue regular, blue bold, blue bold-italics..., then red regular, red bold, etc...), the enhanced (!) flag system would, on the user side, be almost as good as if we were able to create the needed "combined formats" by "clicking together" the dimensions by separate switches (flag plus bold ^b plus italics ^i and so on), on the fly, instead of combining them as preset "sets"... the difference on the user side consisting mainly in sacrificing, for the "everything by flag" solution, quite some shortcuts (key combinations), but in the condition that we could SORT 32 flags, it would be perfectly possible to use'em seemingly!

Again, that might be 10, 12 hours indeed, but not dozens of hours I very much hope. And then, a "major updates" period of about 4 years is very long in comparison, especially considering if / that in-between, there are major improvements... ;-)

(Oh, and I had obviously not been aware that you "hide" the "Hidden" status within the flag formatting, so it's individual and persistent for the db: smart! And if you shared further ideas / considerations on that matter, I'd be happy to add mine again...)