a) Yes

b, c). Probably, but not for gdk-pixbuf, since the set of 
gdk-pixbuf loaders isn't extensible.

#51833 is another related issue. (Another architecture where
architecture specific modules come up is ia64 where you
have both ia64 and ia32 emulation; it's not IRIX specific.)
So, perhaps the search order should be:

 for a in ("$libdir/gtk-2.0/$type/"", "$HOME/gtk-2.0/$type/")
   for b in ("$binver/","")
     for c in ("$target/","")
       look in "$a$b$c"

(Or should home directory location have precendence over 
the system location?)
   

I think it would make more sense to give home precedence over
system.

It occurs to me that 

 $version/$target/$type

is almost certainly a little more convenient than:

 $type/$version/$target

Since it keeps everything for one verson together.

Compare:

 /usr/lib/perl5/5.6.0/i386-linux/[lots of stuff]
 /usr/lib/gcc-lib/i386-redhat-linux/2.96/[lots of stuff]

(These disagree on $version/$target $target/$version, but
I prefer $version/$target since version is more important
for most people using GTK+)

One question is whether we should install in $version/$target
by default, or leave that rearrangement up to people that need it. 
I think, on balance, we should omit the target portion in the default
install setup, since you can have unstable targets on a 
single machine. (We should, however, write the target into
gtk+-2.0.pc.in as we do with the binary version currnetly
so the information is at least available.)

If people complain, we can tweak the install locations later.

Sound good. I don't care very much about $target/$version vs
$version/$target, as long as the same order is used consistently
for all $types. You are probably right that $version/$target is
more convenient for most people, but of course leaving out $target
by default makes the question moot 99% of the time.

Looking at the implementation, remembered why I went with
$type/$version rather than $version/$type ... $version/$type
doens't interact well with GTK_IM_MODULE_PATH, and GTK_MODULE_PATH
since it means you have to specify parent directories of the
directory, rather than the directory itself.

Though it might make sense to replace GTK_EXE_PREFIX,
GTK_IM_MODULE_PATH, GTK_MODULE_PATH with a simple single
path that defaults to $libdir/gtk-2.0 $HOME/gtk-2.0.

See:

http://mail.gnome.org/archives/gtk-devel-list/2002-February/msg00253.html

and folloup(s) for a summary.

Move to 1.3.15, since I don't want to start hacking this until we are
pretty confident.

Mon Feb 18 23:16:16 2002  Owen Taylor  <otaylor@redhat.com>

        * gtk/gtkmain.[ch]: Add routines _gtk_find_module(),
        _gtk_get_module_path() to look up a module of an arbitrary type in
        a standard fashion. (#68474)

        * gtk/gtkrc.c: Make module_path keyword warn and do
        nothing. Remove the im_module_path keyword.

        * gtk/gtkrc.c (gtk_rc_get_im_module_path): Fix
        to return the standard path instead of one determined
        from im_module_path and GTK_IM_MODULE_PATH.
        
        * gtk+-2.0.pc.in: Add gtk_host to go along with
gtk_binary_version.

Reopening this, because I need to remember to adjust the API
docs (it is in docs/reference/gtk/running.sgml).

Oh, I overlooked the fact that you already fixed the docs
(you didn't paste that ChangeLog). Closing now.