Following #2262861: Add concept of collections to config storages, configuration overrides had a base system to build on to store overrides in collections, but no non-test implementation of that existed yet. Language overrides implemented by core are the first practical implementation. Collections allow configuration to store overrides partitioned under the active storage. In the database this is implemented as extra information in DB columns, in file storage (and on export / sync) this is implemented by subdirectories.
Before this change, configuration language overrides were stored within prefixed files, e.g. language.config.de.system.site where language.config was a generic prefix, de was the language prefix and all that follows was the original configuration key/filename. In the new system language overrides use collections named language.de, and so on and the original key/filenames (system.site in this example). This language override would be exported under language/de/system.site.yml when exporting configuration.
This change also introduced LanguageConfigOverride extending from StorableConfigBase, which supports creation/save/delete but does not fire the regular configuration events and does not support overrides in itself of course. The distinct implementation of overrides with their own partitioned storage and behavior allows to apply configuration schemas, the same type casting, etc. to overrides while not firing regular configuration events and not allowing overrides. These were not possible with the previous prefixed-naming-scheme based system.
Finally, to support the installer and syncing process, storage collections can now tell if there is a specific overrider to use to instantiate them. This allows the differentiation of regular configuration and overrides in the install and sync process when we have the files but need to figure out their nature. $config_manager->getConfigCollectionInfo()->getOverrideService($collection) is used in these contexts to figure out how to instantiate an object from the given collection. A full decision tree to use to instantiate configuration objects that may or may not be overrides is as follows:
Read more about configuration collections at https://drupal.org/node/2268523
