The main source of complexity here is that the goal of this project is not to enable a small set of well-known providers (if only!). We need to do that and provide extensibility for providers tomorrow we don't know about today. That's what I mean by 'not enumerable a priori' -- we can't write down the providers we need to support, and we can't write down the settings they'll have.

If we do what you propose we'll still need a registry of enabled providers (different deployments will have different sets of enabled providers configured differently, and code that isn't fully written yet will need to probe and react to that set in order to do things like build the right login form UI, configure the urlspace, etc.). We'll also still need people to implement providers, patch secrets onto settings somehow, and manage the different settings configuration paths for dev/test/prod. That's all doable, but I think the end result would basically end up as complicated as this implementation. So I think the ROI of building it is pretty low, given that this implementation already exists.