They are included using -l flags
exampleX are projects the App would depend on.
aka -lexample1 -lexample2 -lexample3 (for release)
-lexample1d -lexample2d -lexample3d (for debug)
I'm not sure what "Are they included in the list in a manner that gives vsbuild a chance at finding the libraries and checking their modification dates?" means.
It seems like if a dependency is built then the app should recognize that and rebuild.
Well, yes and no. Ideally, yes, vsbuild would be able to infer from your -l directives and the library search path where the library was located and add it to the dependencies for relinking your application, so we knew to relink when the library was modified. I would have to do more testing there may be some things that could stand improvement there, especially with respect to parsing the library path arguments (-L or -R). I can tell you that the way we use vsbuild with dependencies in our project is by specifying the full path to the library we want to link with instead of using -l<lib>. This way vsbuild knows exactly which file to test the modification date of.
The other thing to keep in mind that a dependency is abstractly just saying "execute this build target before you build me". The build target could be anything, one of our projects, a makefile, or something else. The vsbuild tool doesn't know. It also doesn't know if building the dependency actually did anything, or if it was already up to date. Just saying build the dependency does not mean we have to relink. Sure we could add a lot of complexity to make the dependency report what it did, but it wouldn't help any with makefiles and other custom build tools.
So, my advice would be to try changing -lexample1 -lexample2 -lexample3 to "<path1>/libexample1.a <path2>/libexample2.a <path3>libexample3.a", and see if that helps. If it does, then your original projects are a great test case to send us where the -l logic is failing to find the libraries, and we can try to figure out why from that point.