That should work. The VStudio.bld sample demonstrates a project group where essentially that occurs (FirstVB has a reference to SecondVB, and FirstVB gets built if it is up-to-date but SecondVB was built). I've attached a modified VStudio.bld sample that I used to verify the correct behavior in this scenario (adding steps to modify a source file in SecondVB to cause it to be built, and setting projects to project compatibility), and this is the build output:
Processing 'c:\temp\VisBuildPro\VStudio\work\Source\SecondVB\ SecondVB.vbp'...
incrementing version...setting project compatibility...building ('c:\temp\VisBuildPro\VStudio\work\Source\SecondVB \Class2.cls' newer than target)...
Build of 'SecondVB.dll' succeeded.
setting binary compatibility...updating references to project...
Processing 'c:\temp\VisBuildPro\VStudio\work\Source\ThirdVB\T hirdVB.vbp'...
setting project compatibility...not building (no changes)...setting binary compatibility...
Processing 'c:\temp\VisBuildPro\VStudio\work\Source\FirstVB\F irstVB.vbp'...
not setting base address (does not apply for project type)...incrementing version...not setting compatibility (does not apply for project type)...building (reference file 'c:\temp\VisBuildPro\VStudio\work\Executables\Seco ndVB.dll' newer than target)...
Build of 'FirstVB.exe' succeeded.
not setting compatibility (does not apply for project type)...
2 of 3 project(s) updated
If the Build VB Projects step is built again (alone), none of the projects are built; if the attrib+modify steps before it are built and then Build VB Projects is built again, both SecondVB and FirstVB are built again.
If you can tweak the sample projects to reproduce the behavior you're seeing, we can take a look at it. Also see this FAQ for some general recommendations on handling VB builds:
http://www.kinook.com/Forum/showthread.php?threadid=57