"TP", I am following this thread since the beginning and I think your
two goals are legitimate.

The first one (getting read of hard coded strings as much as possible)
seems to have all developers' agreement so far, which is not a surprise.

The second one (changing the way .cfg files are handled) faces a severe
blockage although the first one normally leads to it. The reason is that
the solutions you have proposed raise more problems than they solve,
really If you try to use the strings from any language file for
identifying configuration lines you are inevitably facing all problems
which have been considered already, plus probably a few others that we
have not thought of yet.

My conclusion is that we have to find another solution for the config
files. I have one to suggest which is certainly not perfect but it could
be a base for starting to think in other directions and, maybe, reach a
workable result.

My idea is to keep only the numeric ids of the languqge dependent
strings as the reference and associate them to language files through
some kind of dictionary which would be "internal", i.e. part of the
"code side", as opposed to the "external" side, i.e. the .lang language
files. Nothing much different from now, except that the dictionary would
not be rebuilt every time from the english.lang file, but maintained or
generated internally and would keep permanent associations betzeen
numeric ids and string names.

That way the sequence of the english.lang file would no longer be
critical, same for the national .lang ones, and their maintenance would
be more flexible as a first benefit. After all, even the english.lang
file can experience typos. 8-)

Regarding the config files I would suggest identifying lines by the
"internal" numeric id of the corresponding item, someting like
[numid] national text literal : value
where "[numid]" and ": value" would be the only things which matter for
decoding a config file when loading it.

That would benefit clarity for users who have problem with English,
which you kindly wanted so much.
That should also make reading config files simpler and faster for rockbox..

I already see a few remaining problems like values which are English
words, but there are not so many and all users should probably be able
to live with them if we do not find a more convenient way to solve it.

Relying on numeric ids might also seem subject to errors, but probably
not more than keying mistakes in the current implementation. And there
seems to be a tendency to consider that users should better start from a
config file created by rockbox itself if they want to build their own
ones, and then the risk is lower that they take one for another.