I believe an initial implementation could simply re-run the build.rs whenever it is changed/saved and then re-index everything it writes to (by monitoring which files it opens etc.). Re-running the builid.rs when something it reads changes, may, in the initial implementation be too much work. If so, having to re-save the build.rs to have any changes take effect from its inputs would not be the worst user experience.
If instead of attempting to monitor what build.rs does to figure out its inputs and outputs, would it be possible to add a new file that declares them? Something like this:
Filename: build.decl (contains declarations for build.rs, it not present, build.rs must be run manually by the user re-saving it)
Contents:
[directories.input]
path1=/some/dir
path2=/someother/dirs/*.build.decl
path3=...potentiall other kind of paths, maybe with regex...
[directories.output]
...same...
[files.input]
...same but files rather than directories...
[files.output]
...same...
[other.input]
name1 = "description of other kind of input 1"
name2 = "..."
...
namen = "..."
[other.output]
name1 = "description of other kind of output 1"
name2 = "..."
...
namen = "..."
Maintainers could/should be encouraged to add this file. Perhaps cargo could require it if there is a build.rs. Rust analyzer (and similar tools, including potentially cargo) could leverage this file to know when to re-run build.rs. In addition, if this file were incorrect for what the build.rs does, it would get noticed by a lot of people who were maintaining the crate as analyzer would constantly be getting things wrong if this file were not correct.
The "other.*" options are things that are outside the scope of files/directories and that analyzer (at least initially) cannot monitor and so cannot 100% reliably re-build the build.rs. Analyzer could warn the user that they may need to manually invoke the build or build.rs if any of those resources change.