For now, I'm mostly thinking of using the target identifier itself in the other target-based APIs. But I think we will expand that over time. The tags can be used to mark test targets, which is something we can use as part of test discovery[0]. The languageIds can be used to skip unsupported targets. We can also add our own language-specific data here if we decide to in the future
[0] LSP itself doesn't say anything about tests, but in Xcode we provide structured information about unit test classes and method to allow you to run specific tests from the test navigator.
Ah, that's a good point. Do you have a suggestion? Is textDocument/register too generic?
I see two parts to this: how to choose the subset of targets to include, and how to choose the subset of files from those targets. I don't know that there is a single good answer to choosing the subset of targets to consider, and it probably depends on the kind of user model presented by a particular build system and/or editor. I think the right default absent any other information is to include all targets. If your build graph is really large, you probably need to figure out the right subset.
For choosing files within those target that need to be (re)indexed, the index itself can tell which files are covered by existing index data and whether it is up-to-date.