I've noticed that whenever I reconfigure with CMake Tools, I get 2 TU updates (per visible file). First, in reaction to clearing custom configurations, it starts a TU update using the base config (which can be very slow if that's not a proper config for the file). Then, once custom configs have been generated (async, and a little time consuming due to needing to QueryTranslationUnitSource for each open file), another TU update starts, using the new custom config. Because operations that need a TU will block until TU creation is complete, and the new config does not arrive immediately, the new config does not interrupt the first TU creation. I always have to wait for both to complete.

This issue is tracking reducing this to a single TU update, using the new custom config.

Currently, custom configurations are requested prior to processing didOpen for a file. Then, when a provider calls didChangeCustomConfiguration we clear custom configs, then request and deliver new configs for each tracked file.

Since that was originally implemented, we've added code to request custom configurations on-the-fly (as needed, by FAR/Rename, etc.).

I'd like to rework how custom configurations are delivered. All TU creation attempts could simply leverage the on-the-fly requests. Redundant requests for configuration that cannot be supplied can be avoided by caching 'not available' results for failed config requests.
Instead of delaying didOpen, we could send that immediately. When we receive didChangeCustomConfiguration from a provider, that could simply deliver a single update to the native side to trigger discarding of cached custom configurations and 'not available' tracking, and trigger TU recreation.