One more comment: Meanwhile I noticed that GTK+ now also parses
theme and key theme rc files, but this works differently.

GTK+ parses only the first found of 

~/.themes/$gtk-theme-name/gtk-2.0/gtkrc 
${prefix}/share/themes/$gtk-theme-name/gtk-2.0/gtkrc

and the first found of 

~/.themes/$gtk-key-theme-name/gtk-2.0-key/gtkrc 
${prefix}/share/themes/$gtk-key-theme-name/gtk-2.0-key/gtkrc

I think there should be a unified algorithm for determining
which rc files to parse. My proposal would be: 

The locale-specific fallbacks should be tried for all rc
files (I imagine they would be especially useful for key themes).
Always parse all found files, with the more specific matches
being parsed later. The specificity would be defined as

1) Home directory is more specific than system location
2) matching more parts of the locale is better

Locale specific RC files are much less needed now than they
were for 1.2.x, since font selection is not not typically
done in RC files ... instead you set up your aliases. 

Encoding specific RC files are never useful now and support
for that should be dropped.

I'd agree that it makes sense to reverse the order of the
parsing ... it wasn't very necessary for 1.0/1.2 since
fontset always overrode font in RC files, and locale specific
RC files genreally contained fontsets while non-locale
specific RC files contained fonts if anything.

I'm not really sure if merging together themes in your home
directory with system themes makes sense ... it would allow
tweaking of system themes, yes, but if you happened to have
the same theme in both places, the results would be very
unpredictable. (Merging can add things, but it never removes
anything.) I think I'd prefer to say that if people want
to tweak, they need to do an explicit include. 

It turns out that people aren't very fond of locale specific
key bindings, even for menus, and the key bindings that would
be configured here typically avoid the "numeric" keys altogether,
but there may be some uses. (In general, the assumption that
keyboard and locale go together is very poor, so locale
specific RC files shouldn't be used for dealing with things
like the Germna +/= placement.)

Localization of icon themes is probably a bigger reason for
local specific theme RC files and important enough to make
it a good idea to support.

How about the following slightly adjusted algorithm then ? 
I think it addresses your concern about theme merging. It has 
the added benefit of changing the rc file lookup to what was 
described in the docs (until I changed them recently to match the 
implementation).



The locale-specific fallbacks (ie <file>.en_US and <file>.en) 
should be tried for all rc files. Only the most specific found file 
is parsed. The specificity would be defined as

1) Home directory is more specific than system location
2) matching more parts of the locale is better

Hmmm, as much as I think it would be nice to have simple rules,
I'm not sure that is possible. I think the right set of rules
is:

Looking for a file:

 1) When attempting to parse a RC file for a named theme, look for, 
 in sequence:

    path = ~/.themes/$gtk-theme-name/gtk-2.0/gtkrc
    path = ${prefix}/share/themes/$gtk-theme-name/gtk-2.0/gtkrc

  If one of these files is found, Load(path). (see below)

 2) When looking up a RC file for a 'include' directive,
 if the specified filename is absolute, Load(filename.)
 If the path is relative, then defining 'dir1' as the
 directory where the RC file currently being parsed is,
 'dir2' as the directory where the RC file that includes
 that file (if any0 is, and so forth, then look for,
 in sequence:
  
   path = $dir1/$filename
   path = $dir2/$filename
   ...

 And if one of those is found, Load(path) and stop.

 3) When looking up a RC file specified by a call to
    gtk_rc_parse() or gtk_rc_add_default_file(),
    if the filename is absolute, Load(filename), otherwise
    Load($cwd/$filename)

Loading a fully qualified path:

 If $file exists parse that.
 If $file.xx_YY exists, parse that
   otherwise if $file.xx exists, parse that

I think I have this all implemented now, with:

Sat Feb  2 21:54:01 2002  Owen Taylor  <otaylor@redhat.com>

        RC file lookup improvements (#68234, suggestions
        from Matthias Clasen.)

        * gtk/gtkrc.c (gtk_rc_parse_file): Look for the 
        locale suffix variants (gtkrc.en_US, gtkrc.en) for
        all RC files we parse, not just the default RC
        files.

        * gtk/gtkrc.c (gtk_rc_parse_default_files): Remove
        support for charset specific RC files.

Being the missing piece. So, the main remaining thing is to
to get the above description cleaned up and in the documentation.
(Well, assuming that we are happy with it.)

I am happy with it and have adjusted the docs to match the code.