I can't get the Build in Project intermediate option to work for code that consists of a sketch + shared code library. While searching for a suitable setup, it seems that the combination Build in Project intermediate + Deep search does not work in VM, and turning Deep search for libraries off doesn't work either. I'm stuck and don't know how to proceed.

Context:
I'm using VM + VS2022 + git. I've got a basic VM/Arduino project that contains code matching a devboard (+ SD card + wifi support). I use the project as a starting point to explore new devices: copy the project, add device specific code, run. Sometimes I need to extend the basic project, so I make a new clone of the git repository (and select another branch) and work on the basic project from a different file location. The default settings of VM are not suited for this: the build location is global, depends on the VM-application name only, libraries are in global locations, etc. So I'm trying to change the settings to make all development/debug processes local, i.e. relative to the location of the VM-project (or VS2022-solution, if that is easier).

My code consists of:
- A shared code library (called Devboard) with the basic functionality
- A VM-project with an almost empty .ino sketch (with setup and loop only) that includes the header from the shared code library
- User installed libraries that are copied into the VM-project's Libraries folder as shared code libraries
- The headers of the user installed libraries are included in the source code of the shared code library (DevBoard)

I've tried several things (see attached log files - I've deleted all build output between the tries):
- If Build in Project intermediate is off and the AppData build location is used, the application builds as expected and functions properly. In this case, turning Deep search for libraries on or off has an effect on the compilation process, but both succeed.
- If Build in Project intermediate is on and the project's obj directory is used, Deep search only detects the inclusion of the shared  code library (DevBoard). The compilation of the source code of the shared code library should have triggered the inclusion of the user installed libraries, but that doesn't happen. The compilation fails because of the missing library build results.
- If Build in Project intermediate is on and Deep search is off, only the user installed libraries are compiled before the sketch is compiled. That fails because the shared code library (DevBoard) is not involved in the compilation process. I've tried turning Shallow Library search on and off, but that does not seem to make a difference.
- I've added a dummy code file (.cpp in src) that includes a header from each user installed library to the VM-project. With Build in Project intermediate and no deep search, the user installed libraries are detected and compiled.

Apart from the inclusion of the user installed libraries, all three cases with Build in Project intermediate fail because the shared code library is not compiled (but it is copied to the intermediate directory).

I'm not sure how to proceed. The issues related to Build in Project intermediate seem to be due to the way VM works, and I have not discovered any options to influence the build process. Help! Because of the long compile times I would like to have a working setup for the combination Build in Project intermediate without deep search.

I'm worried about the intellisense information that is still kept at a global location in appdata and will conflict for the various instances of the VM-project in the clones.
(I've read the discussion at
https://www.visualmicro.com/forums/YaBB.pl?num=1645964879/3, which seems to address a similar problem.) I'm puzzled by remarks about "a lot of disk space" when each directory seems to hold only a couple of MB - breadcrumbs in a world with TB-size disks. Having everything local to a project is a much better idea, because when I'm finished with a project I delete the git clone and the used disk space is zero. When I revisit the project, I should be able to pick up where I left off by simply creating a new git clone. Is there a way to relocate the intellisense cache to a project-specific location?

I would also like to add the system libraries to the project's Libraries as shared code libraries to the project. After the project I'm working on is completed, it may be in deep sleep for some years. If then something breaks and I have to replace a sensor with a new model, I would rather spend the time programming the sensor rather than finding out why the user installed libraries do not work with the system libraries of a fresh VM/Arduino-installation. Is there an option to do that? 

Thanks for the link to the library documentation, I'll look into that.

Fiddling with the Intermediate Directory indeed helps. (Turned off deep search, no dummy code file.)

The Intermediate Directory is $(ProjectDir)obj\$(Platform)\$(Configuration)\ by default. It does not help if I change it to something else that is within the $(ProjectDir). But if I set it to $(ProjectDir)..\test the shared library code (DevBoard) is compiled.

Indeed it works for any folder that is not within the project directory. In my case:

<solution folder>
    <shared code library>
    obj => works
    <subfolder>
        obj => works
        <projectdir>
            Libraries
                <clones of user installed libraries>
            obj    => doesn't work

The same is true if the subfolder is removed so the projectdir is a direct sibling of the solution directory.

You cannot fool VM/compiler by using an Intermediate Directory of $(ProjectDir)..\projectname\obj, that doesn't work either.

What is the rationale behind this? I don't understand why this works. The rule seems to be: if a project uses shared code (or library code?) that is located outside of the project directory, the Intermediate Directory must also be outside of the project directory. Is this a bug or is it some kind of feature that I should have known about?

Checked that as well: it doesn't matter where the libraries are located. If I move them to <solution folder>\test\Libraries and include the library's shared code project in the VM-project, the library is compiled regardless of the value of the Intermediate Directory. So it must be due to a difference in handling of library/non-library shared code projects.