At the moment chained config files evaluate variables in the order they are parsed. This means that the following case

# a.ini
output = %(var)s

# b.ini
use = config:a.ini
var = B

# c.ini
use = config:b.ini
var = C

will produce output == B, because b.ini is parsed after c.ini (as dependency) and thus var from b.ini overrides c.ini version.

As a result, one can't use inside c.ini any variable that is defined in a.ini or b.ini (because these files are not parsed yet)

I think that python-like behavior is more appropriate in that case. When class C(B): ... is defined, we expect C to override values from B and not vice versa. The only exception is the here variable - it must never be overridden and must always refer to the file where it used.
Keeping this special case in mind, I've updated the logic. Now configuration files are parsed starting from the last file in the chain (a.ini in the example above), values that contain %(here)s are evaluated immediately and all other values are evaluated when parsing is finished.
Note: that means that now [DEFAULTS] from the top-level config (c.ini) has higher precedence. Previously [DEFAULTS] from the very last file (a.ini) were used. Thus it's a breaking change, but I think it still can be backported to v2.9.4