For me, that's a great drawback of geany vs. lexilla source code. Every time any lexer feature is added to lexilla, highlightingmappings.h needs to be updated manually, keeping order troublesomly. I'm not sure, but even now, there are differences.
If you mean things like `lexer.cpp.track.preprocessor=0` then no, it can be done dynamically in the config file independently of highlightingmappings.h.
But if a new highlighting style is introduced by a lexer, Geany indeed has to update `highlightingmappings.h`. I think the reason for this was to have nice names in the config file like e.g. `commentline` for Python instead of `style.python.1` in SciTE but this is at the cost of some extra maintenance. But it's probably too late to change that for all the languages.
Examples of discrepancies:
Not discrepancies IMO, see below.
lexer Pascal has properties lexer.pascal.smart.highlighting fold.comment fold.preprocessor and fold.compact Geany does use lexer.pascal.smart.highlighting (in filetype.pascal lexer.pascal.smart.highlighting=1), but in highlightingmappings.h there is entry #define highlighting_properties_PASCAL EMPTY_PROPERTIES.
That's alright. In general, properties should be defined in the config file instead of being hard-coded.
lexer CPP has about 20 properties defined. Two of them are used in geany (in filetype.c styling.within.preprocessor=1 and lexer.cpp.track.preprocessor=0), but in highlightingmappings.h there is entry "fold.cpp.comment.explicit", "0".
And if users wish, they can add whichever of those 20 properties to the config file and customize the lexer to their needs. I don't know why `fold.cpp.comment.explicit` is hard-coded - possibly some things in Geany don't work if this property is set to 1.
lexer CPP currently has defined 6 keyword lists. In highlightingmappings.h there is entry only for 0 primary 1 secondary and 2 docComment. The drawback extends deep into the source code. For example, here geany uses wordlist 3:
Basically I think nobody from Geany developers (or even users) needs 6 keyword groups so only 3 are defined. If there's a need, we may add more.
The wordlist 3 is indeed "magic" as it serves for injecting types from ctags to Scintilla and their colorization. If I'm not mistaken, we do this only for a few languages now, mostly using the C lexer so there hasn't been much need to define it dynamically.
I propose to introduce keywordlist constants: SCE_[LANG]_K_[DESCRIPTION] and rename existing style constants SCE_[LANG]_[DESCRIPTION] to SCE_[LANG]_S_[DESCRIPTION]. Keywordlist constants can be used in highlighting_keywords_[LANG] and in source code (e.g. in document.c, see above) and will improve readability and reduce fault liability SciLexer.h: SCE_C_K_GLOBALCLASSESANDTYPES = 3; and document.c: keyword_idx = SCE_C_K_GLOBALCLASSESANDTYPES;.
If you want such a change, you must do it in Scintilla - "SciLexer.h" isn't our code and as I said, it's generated dynamically using a script in Scintilla. I slightly doubt it will be accepted though.