A setting contains all parameters that are needed to configure the device to a state it was in when the setting was created. Every image can be captured with a completely different set of parameters. In almost every case, these parameters are accessible via a property offered by the device driver. A setting e.g. might contain

The gain to be applied to the analog to digital conversion process for analog video sources or
The AOI to be captured from the incoming image data.

So for the user a setting is the one and only place where all the necessary modifications can be applied to achieve the desired data acquisition mode. There is however an important difference in behaviour between different interface layouts. See here to find out how to modify the interface layout or check in the API documentation for the interfaceLayout property of the class Device.

When working with the DeviceSpecific interface layout, each frame will be captured with the settings as present when requesting the image. Every parameter can be modified at any time. When requesting another image the settings valid at that moment will be used to fill this buffer with data
For the GenICam™ interface layout all device properties modified during a continuous acquisition will be applied at once so might affect this or the next image transmitted by the device. Depending on various parameters (the number of buffer already captured but not collected by the application, the way the device internally operates(e.g. has already captured a couple of images that await transmission), etc.) this will have impact on that captured images somewhere in the near future thus when a precise moment to change settings is needed, continuous acquisition must be stopped and then restarted after modifying the features. Certain features (typically those affecting the buffer layout/size) cannot be changed while a continuous acquisition is running in GenICam™ interface layout anyway.

Now, whenever a device is opened, the framework will execute following procedure:

ImpactControlCenter - Device setting start procedure

Please note that each setting location step in the figure from above internally contains two search steps. First the framework will try to locate a setting with user scope and if this can't be located, the same setting will be searched with global (system-wide) scope. On Windows this e.g. will access either the HKEY_CURRENT_USER or (in the second step) the HKEY_LOCAL_MACHINE branch in the Registry.
Whenever storing a product specific setting, the device specific setting of the device used for storing will be deleted (if existing). E.g. you have a device "VD000001" which belongs to the product group "VirtualDevice" with a setting exclusively for "VD000001". As soon as you store a product specific setting using THIS device, the (device specific) setting for "VD000001" will be deleted. Otherwise a product specific setting would never be loaded as a device specific setting will always be found first. Storing a product specific setting with a different device belonging to the same family however will NOT delete device specific settings for other devices.
The very same thing will also happen when opening a device from any other application! ImpactControlCenter does not behave in a special way but only acts as an arbitrary user application.
Whenever storing a device family specific setting, the device specific or product specific setting of the device used for storing will be deleted (if existing). See above to find out why.
On Windows framework will not look for a matching XML file during start-up automatically as the native storage location for settings is the Windows Registry. This must be loaded explicitly by the user by using the appropriate API function offered by the SDK. However, under Linux XML files are the only setting formats understood by the framework thus here the framework will also look for them at start-up. The device specific setting will be an XML file with the serial number of the device as the file name, the product specific setting will be an XML file with the product string as the filename, the device family specific setting will be an XML file with the device family name as the file name. All other XML files containing settings will be ignored!
Restoring of settings previously stored works in a similar way. After a device has been opened the settings will be loaded automatically as described above.
A detailed description of the individual properties offered by a device will not be provided here but can be found in the C++ API reference, where descriptions for all properties relevant for the user (grouped together in classes sorted by topic) can be found. As ImpactControlCenter doesn't introduce new functionality but simply evaluates the list of features offered by the device driver and lists them any modification made using the GUI controls just calls the underlying function needed to write to the selected component. ImpactControlCenter also doesn't know about the type of component or e.g. the list of allowed values for a property. This again is information delivered by the framework and therefore can be queried by the user as well without the need to have special inside information. One version of the tool will always be delivered in source so it can be used as a reference to find out how to get the desired information from the device driver.