Description
Is there a specific reason that value resolution is controlled centrally from within the ConfigurationRoot?
By that I mean that Configuration[key] currently calls TryGet(key) on each provider in order until it gets a value. This also means that providers know nothing of one and other and cannot react in any way to the values provided by the others.
Disadvantage of current design
As it stands any customization which departs from the current each provider layer independently adds keys behavior requires changing ConfigurationRoot. Unfortunately, as ConfigurationRoot is hardwired into the ConfigurationBuilder, one cannot easily switch out the default implementation with a custom one.
My vision
I envision a pipeline like architecture (comparable to the middleware pipeline) where each provider is responsible for calling the next one in line. When a value is requested for a key, each provider (starting from the first/top one) gets to decide if it can (or wants to) provide a value and can otherwise delegate the request to the next provider in line. This would still allow replicating the current behavior but it would also support "interceptor-like" providers which can modify (or hide) values from the underlining provider layers.
Effect
This would allow implementing things like resolving references or value interpolation (or any other kind of intercepting value modification) fairly easily as additional "provider" layers, with the additional advantage that those would be optional and customizable at the (framework-)users discretion.