Introduction

Modules such as Config Split want to modify the configuration when it is synchronized between the database and the exported yaml files.
This module provides the API to do so but does not influence a sites operation.

Writing tests for modules using Config FIlter or the core API

Config Filter comes with test traits that can be used to write tests for modules with config filter plugins and that want to refactor to use the new core API. The tests written with the config filter test traits will work without change when the module uses the core API. We may add these test traits also to drupal core.

How it works (1.x)

Configuration Filter swaps the config.storage.sync service from Drupal 8 core.
The new service wraps the file storage and applies filters to it.
This allows other modules to change the configuration as it gets imported or exported both in the Drupal UI and with drush.

CMI in Drupal core and config_filter

Config Filter 1.x is compatible with all supported versions of Drupal core above 8.4. In particular it is compatible with 8.8 and Drupal 9 and above. It works in a completely different way than the new API that was added to Drupal 8.8. Both approaches work in parallel to each other.

Config Filter 2.x is compatible with only Drupal 8.8 and above and is meant to be a bridge between the Config Filter API and the new core API. So modules compatible with Config Filter 1.x are compatible with Config Filter 2.x because the API of Config Filter (ie the filter plugins and manager are exactly the same.) However Config Filter 2.x does no longer wrap the sync storage but instead interfaces with the new event system from Drupal core.
That said, some automated tests may have to be changed to trigger the new events rather than just accessing the sync storage. It is recommended to use the test traits to this effect.

Why would you use Config Filter 2.x?

If you update to Drupal 8.8+ and have Drush 10+ and use some modules that use the new Config transformation API you can use Config Filter 2.x to make sure all custom and contrib modules that depend on Config Filter use the new event system. This may help with debugging because all transformations happen at the same time instead of altering the configuration in two different places.
In the long run it is recommended that modules refactor to use the new API from Drupal core instead of Config Filter since it was inspired by Config Filter but improved to alleviate some of the pain points.

You may want to stick with Config Filter 1.x because it is likely more performant and modules were written against Config Filter 1.x. This would avoid subtle bugs. But really you would want to motivate modules to be re-written for the new core API. Config Filter can help writing tests that work both with the config filter API and the core API without a change. These tests are the same in 1.x and 2.x

RTBC issues for Config Filter

Filters