That is a very good point and that is the reason why I am pursuing an implementation that reuses the work from the existing fontification code.
My goal is to use the `sh-feature' function to retrieve everything that needs to be fontified for the buffer's shell variant.
It has worked well for most built-in commands (e.g. alias & source) but not as great for reserved words like "time" and "coproc". As Stefen pointed out, some reserved words complicate the grammar, so I believe that is the reason why the tree-sitter-bash folks decided to keep them out of the grammar.
This becomes a nuisance because then I have to use two queries to match keywords. One simple query to match the recognized keywords and another that matches all commands but only fontifies the ones that belong to the un-recognized list. To build such a list I have to explicitly construct a list of recognized keywords using literals and that goes against my goal of reusing pre-existing functionality by relying on `sh-feature'.
Built-in commands are a lesser nuisance as some of them (e.g. local, declare, and typeset) are not commands but declaration_commands in tree-sitter-bash grammar. But for those I just have two queries and I don't need to create a variable per shell variant.
Aside from that, I am trying to extract the keywords in `sh-font-lock-{var, var-1, var-2}' variables to replicate the fontification based on the level selected by the user. But parsing those is more intricate as the return is a list where each element is either a list of the form:
- (regex level font-face), or
- (regex list [list]), where list is of the form (level face) or (level function function-args).
The logic to parse those I believe exists within font-lock-mode or font-core, but I am not sure if I would be able to use the forms above as they use functions that depend on variables that the user might tweak. I don't know if the compiled queries in *-treesit-settings would be recompiled to achieve the same flexibility as the existing fontification code.