I suggest that your question reveals that you have outgrown app.config--it is time to move on to a better solution, and to begin addressing some related issues.
For one, you should NEVER automatically deploy a configuration file to production, and you should expect the operations support personnel to vehemently reject any attempt to do so. Of course, if you are the operations support personnel, then you should reject it yourself. Instead, your release should include some instructions for manually updating the configuration file, with a sample for illustration. Production configuration is too important for lesser measures, unless you simply don't value your production system much.
Likewise for test and other environments, but to a lesser degree, so you really only need your app.config populated for your own development work.
An option is to embed the multiple configurations into a single app.config, which is reasonable for small, relatively unimportant applications or in early stages of development/release. For example, create a configuration setting called something like target-env that contains a value that you use in your code to select other configuration settings, such as by prepending the value onto the keys of the other configuration settings.
My preference is to move past app.config altogether, or to use it minimally. In this case, I prefer to put just enough configuration data into a file to allow my application/system to connect to its database(s), then I put the remaining configuration details into a special database table for that purpose. This has lots of advantages, such as making the database "aware" of what environment it represents (dev, test, production, etc.) and keeping the configuration and the other data together. The deployment package can then properly be kept dumb regarding configurations and environment differences--the code just accesses its configuration data and acts accordingly, so the same deployment package is good for any environment.
However, a key success factor to this approach is that your application code must "know" what it expects for configuration and it must "know" to reject an improper/incomplete configuration. This is where you should spend your time, not trying to work around the limits of app.config.
That usually means creating your own class for accessing configuration data, then using that class throughout your application instead. This also leads to many other benefits, such as strongly-typed configuration data: instead of a String, return a DateTime, or a Url, or an Integer, or a Currency, or whatever best fits the configuration data and the application.