Confused by the config hierarchy loading/caching model

[Omnikron13]

I'm struggling to understand the design/rationale behind how a config file hierarchy is intended to be handled here.

From what I can see, the design is that for every potential config option/key a new copy of the hierarchy of applicable config files, then when the config value is first accessed the files are read and unmarshalled until a config file with the setting is found, with the unmarshalled data cached for the next time that config value might be read?

The problem I'm having is, it seems like every chain is storing its own copy of the paths, and subsequently caching its own copy of the unmarshalled data?

While I can see potential merit in lazily processing the config files, the fact the data isn't centralised and is getting duplicated seems like a big problem. Aside from the obvious concerns of efficiency, if a config file (or file hierarchy) is getting read out once when value foo is first needed, and then again when value bar is first needed, then (assuming it is possible a config file could be changed during program execution) you could end up with an inconsistent and maybe invalid or even dangerous configuration state.

Also I've only skimmed over the entirety of the ValueSource/ValueSourceChain code just now, but it doesn't seem like there is anything in place there to prevent chains for duplicate keys being created there, so isn't it possible that somebody could pretty trivially create more than one config chain for the value foo, meaning that you could potentially end up with not only incompatibility between keys if config files get modified, but inconsistencies over what a given config value actually is in different places in a codebase.

Apologies if I'm just short on sleep and caffeine, and have missed something key in the design here. But to my reading right now it seems like there are pretty fundamental flaws in how config files are being read, processed, and cached, along with how the YAML() et. al. functions/API is designed.