This has been implemented generally in Horde 4, for all configuration 
files, in all applications.

Ok, it was just a proposal.
Seemed like the straight forward thing to do to apply the same 
strategy that is used for all other configuration files (at least in 
Kolab) also to this one, given also that Kolab ships its own 
10-kolab_backends_base.php to override the dist backends.php:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webclient/ingo/configuration/ingo-1.2.3/
We applied the patch to be able to layer configurations (Horde, Kolab, 
UCS) and ship 20-backends_ucs.php to have a standard clean path to 
override (Horde, Kolab) settings if requirements change at some point.
Ok.

Ah, sorry, we were talking about completely different things. The code 
in Turba you were talking about is a Kolab modification that doesn't 
exist upstream either.
I thought we already had some generic *.d/ loading code in Turba that 
you were referring to.

So, let's reboot the discussion:
- First of all, these changes should go into the development aka git 
version of Horde and apps.
- It looks like we only support .d style loading for registry files 
from horde/config/registry.d/
- The rationale for loading registry stanzas from a directory makes 
sense, but what's the exact reason why you need this for backend 
configuration files in Turba/Ingo?
- If this going to be done correctly, it should be done in 
Horde::loadConfiguration().

I see, fine we agree on the approach, since this is exactly what I did 
to provide the patch attached to this report: I took the following 
kolab patch for turba as the example, and did *not* find a 
corresponting code block in ingo-h3-1.2.3, so I thought it might be 
helpful to file the patch for ingo/config/backends.php.

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webclient/turba/patches/turba-2.3.3/t_turba_HK_GW_ConfigurationOverride.diff?rev=1.1&content-type=text/vnd.viewcvs-markup

If you consider the patch as futile we would be glad for a hint as how 
to choose an alternative approach to a conf.d-style solution in this 
case. If you consider this patch as obsolete, feel free to close this 
bug as invalid.

Of course not. You want to load backends.php, so why would you look 
for sources.php? And if there was some support for config/*.d/ 
loading, you wouldn't have to write the patch. I asked you to look 
into Turba as an *example* how to correctly load config files from a 
*.d/ directory.

Ok, I see how it is done in turba, but in ingo-h3-1.2.3.tar.gz I could 
not locate a config/sources.php or any place where any pattern like 
config/*.d/*.php gets loaded. Thus we fixed this with the patch 
attached.

Ping?

Like with Turba, this code must not be added to the base configuration 
itself, but to the place(s) where config/source.php is loaded.

The attached patch adds the include loop to backends.php for loading 
configuration stanzas from a backends.d directory. The code was copied 
from the sources.php.dist in Turba.

This include loop seems to be missing in ingo 1.2.4 as well.