The config information isn't typed, so there's no way for the automagic to use anything that doesn't fit exactly with the plugin trying to use it. If instead we types configs as they're saved, then the automagic has a chance of traversing down a tree and reusing some of the automagic (or trying to).
Step 1: Tag complex config types with a $type or some other unique name. Since values are hierarchical, we could provide this value below each entry type, but this may be overkill, since we don't really need the types for standard strings or numbers etc. We could always introduce it later if needed. Each tree should be complete down to its leaves, so we don't need to worry about missing bits further down the tree.
Step 2: Once everything is properly typed, write a new automagic run early that passes over the requirements tree and tries to populate it partially using the data that's available.
Step 3: Double check and tidy up existing automagic to check they do things the right way, and can still make use of partial information appropriately.
The config information isn't typed, so there's no way for the automagic to use anything that doesn't fit exactly with the plugin trying to use it. If instead we types configs as they're saved, then the automagic has a chance of traversing down a tree and reusing some of the automagic (or trying to).