When a configuration is parsed, include paths and forced-includes (and frameworks, etc.) are processed in order to canonicalize paths and resolve relative paths, etc.. If an path/file cannot be found when the configuration is parsed, it's omitted. This leads to having to reload the window after those paths/files are created, in order for them to be picked up. (In some cases, making an edit to c_cpp_properties.json would also work).
Perhaps unresolved paths could be retained, and retried later.
Whenever a change is detected, it would be possible to reset all TUs that would be affected. Though, it's unlikely all filesystem changes could be reflected immediately - perhaps only when a new TU is created.
There are some scenarios that would not be easy to handle without significant overhead, such as if a symbolic link was updated and caused a previously resolved path to translate to a different canonical path. So, there would likely continue to be scenarios that would require reloading the window.