+1 to what @BillyONeal said earlier.

What you originally proposed won't achieve what you want. The fundamental you want to get to is one install tree with one install command.

It sounds like you are trying to address 2 constraints:

1. You need to avoid version conflicts throughout your dependency graph, even though not all dependencies are consumed as vcpkg ports.
2. Your internal vcpkg ports (B & E in the example) need to also be available as project submodules or something similar rather than always being consumed as ports. Let me know if I misunderstood something here.

Our proposed solution allows you to configure your projects such that you can call "vcpkg install" on project F to resolve your dependencies, before building it with the Makefile, while respecting the constraints above.

This requires several steps:

1. Create overlay ports for B and E, each with stub portfile.cmake files and vcpkg.json files (that reference C and any other upstream dependencies). When these are used, B & E will not actually be built through vcpkg directly, but vcpkg will still install transitive dependencies like C. The portfile.cmake files would be mostly empty, but should still be configured with appropriate policies, similar to: https://devblogs.microsoft.com/cppblog/using-system-package-manager-dependencies-with-vcpkg/.
2. The overlay vcpkg.json files should be a symlink to the original vcpkg.json files for B & E. Put the symlink and portfile.cmake files in separate sub-directories of B/E without any other files at that location. This is to avoid a potential performance issue where "vcpkg install" may otherwise waste time unnecessarily.
3. The vcpkg.json files for Projects A and D can reference the overlay ports when you want to build B & E separately or reference the original ports directly when you just want to consume them as vcpkg ports.
4. Configure some CMake variables for B & E: Set VCPKG_MANIFEST_DIR to the directory F is located in, turn off VCPKG_MANIFEST_INSTALL, and set VCPKG_INSTALLED_DIR to a common directory like F/vcpkg_installed. Also see the docs: https://learn.microsoft.com/en-us/vcpkg/users/buildsystems/cmake-integration#vcpkg_manifest_dir
5. Your Makefile for F should run "vcpkg install --overlay-ports:/overlays" early on, before the step where it runs cmake configuration on B & E.

You would still want to have a vcpkg.json file for project F as well as some vcpkg.json files for A and D. The manifest files for A and D would determine if you are using the overlay ports or the original ones. When you run "vcpkg install" it should be run at the project F level

Below is an example directory structure:

/Makefile                      -- F
/A/Makefile                    -- uses 'B'
/D/Makefile                    -- uses 'E'
/B                             -- submodule for 'B'
/B/CMakeLists.txt
/B/vcpkg.json                  -- definition & deps for 'B', such as 'C'
/E                             -- submodule for 'E'
/E/CMakeLists.txt
/E/vcpkg.json                  -- definition & deps for 'E', such as 'C'
/overlays                      -- intra-workspace overlays
/overlays/B                    -- stub overlay for B
/overlays/B/vcpkg.json         -- symlink to /B/vcpkg.json
/overlays/B/portfile.cmake     -- Empty portfile (with appropriate policies; see [1])
/overlays/E                    -- stub overlay for E
/overlays/E/vcpkg.json         -- symlink to /E/vcpkg.json
/overlays/E/portfile.cmake     -- Empty portfile (with appropriate policies; see [1])