From a .NET Framework point of view (not speaking of tools - Visual Studio - for the moment), historically, there was only [app.exe].config (in fact, it's what the AppDomain defines as the configuration file. The name is defined by the AppDomain, that's why it's web.config for web apps...) and machine.config. 'app' is deployed together with the application, 'machine' is for the whole machine. They were supposed to be 'quite' read-only for the average user. It's possible to change them, but it was not the idea.
But how can I save end user preferences then? That's why [user].config was introduced (I believe with .NET 2). The official documentation says this:
The configuration system that was originally released with the .NET
Framework supports providing static application configuration data
through either the local computer's machine.config file or within an
app.exe.config file that you deploy with your application. The
LocalFileSettingsProvider class expands this native support in the
following ways:
1) Application-scoped settings can be stored in either the machine.config
or app.exe.config files. Machine.config is always read-only, while
app.exe.config is restricted by security considerations to read-only
for most applications.
2) User-scoped settings can be stored in app.exe.config files, in which
case they are treated as static defaults.
3) Non-default user-scoped settings are stored in a new file,
user.config, where user is the user name of the person currently
executing the application. You can specify a default for a user-scoped
setting with DefaultSettingValueAttribute. Because user-scoped
settings often change during application execution, user.config is
always read/write.
So from a .NET Framework point of view, there is only one 3-layer mechanism.
Now, Visual Studio just tries to help you by generating the type-safe code for the final read/write settings. Most of the time, that [user].config file does not exists and a setting value will be defined by what's in the DefaultSettingValueAttribute (defined for each setting), or use what's been defined statically in the app.config. That's why Visual Studio also updates the app.config file so you can define static defaults to the settings. But you can perfectly delete all that app.config stuff.
