Can we 1st determine exactly what pain-point we're trying to solve here? Or, at least, prioritize them?
It seems to me that if the main issue is runtime re-configuration during the request/response phases, then that really forces us into something which must be very lean, mean and FAST. By extension, this also provides to us a way to really clean up and standardize our current config mess. If however, our focus would be to make our config files cleaner and prettier, then I fear that by the time that trickles down to how that interacts with the actual runtime processing, we'll get nasty performance. I'd prefer optimum runtime and let that drive how it gets exposed to the admin, rather than the reverse... And then we can see if that pain is worth it :)
