What I meant to say in my withdrawn post above (which I canceled because I felt it did break the forum policy of not speaking in a manner that would be inappropriate in person) is this:
The need of Projucer to generate multiple projects in Visual Studio seems to me like a way to mimic the behavior of Xcode, where you can set a target to be built as a dependency of another target. This is not possible in Visual Studio, where this build dependency can only exist between projects.
Given that limitation, I wonder if it wouldn't be better for Projucer to generate a Solution with a more conventional structure:
One Project to build the whole codebase of JUCE, to be reused by each plug-in format. Such project would be roughly equivalent to the one labeled "Shared Code" of this new structure committed yesterday.
Another project containing the actual plug-in sources. This project would need as many targets as many formats it needs to generate (for example AAX, VST2, Stand-alone, possibly duplicated to have a Release and a Debug target for each format).
This reduces the number of needed projects in the solution from "one per format, plus a 'Shared' one", to "always two".
Also, if you look at it, you can recognize that as a conventional design: name the project #1 "JUCE" and build an actual library out of it (I mean an actual .lib file), and then use that as a dependency to be linked by the project #2 that builds the actual plug-in (and that should named after it).
That is exactly how JUCE was built back in the days of ver. 1.xx.
I'm not a particular fan of that method, and I am sure Jules is neither, but I should objectively admit that it looks better than a proliferation of Projects in the Solution.
Also, please consider that so many of the configuration issues that made building the JUCE.lib file a complicated thing back in the days (and that probably contributed to the frustration of Jules, in the form of users requesting how to do it and having problems with it), would now be made a lot easier by mean of the Projucer.