Hi Jon,
As Artur mentions, we see the issue you provided and we are determining if this is a workflow that we can and should directly support.
In essence, the SDK developer shell configures provides our build environment with the least required configuration to do its job. e.g. set MS, MSMDE, and DEFAULT_TARGET_PROCESSOR_ARCHITECTURE, include, library, and bin directories. With that base information when you execute bmake against a valid working make file, it pulls in additional dependency search and configuration steps performed via policies and conditional make includes. For instance early in the build config environment processing if you require setting a different version of Visual Studio you can do so by defining and overriding the default value of BUILD_USING_VSxxxx (DefaultToolSet.mki). As the build environment continues to configure defaults for the default build tools AssertToolSet.mki is the workhorse that implements the "supported toolsets" for the VS version specified (or the correct defaults the SDK requires).
As you may have discovered, the Microsoft Visual Studio project file (.vcprojx) does not provide any overriding properties for: TargetFrameworkVersion or TargetFrameworkMoniker, that would instruct msbuild to use a specific toolset to compile and link project files. Since we use the SDK environment and minimal VS project solution properties in most cases having all the necessary overrides defaulted by the tools defined, we would need to investigate if we can or should support a set of changes each VS project would require to build in a minimal yet still portable "stand-alone" configuration. This would include moving make includes and library references to explicit paths and libraries to reference in each separate project, where the default locations can readily be searched and resolved and overridden safely with our current approach.
As for why you cannot directly edit the VS project properties and get the Microsoft error when doing so (and not having much time to review this deeper), I can only suspect that this post may provide some additional insight or direction as to why, or to identify the essential terminology when asking this as a msbuild type question (if needed). See: How to: Target a Version of the .NET Framework
HTH,
Bob
TIP: To obtain the most verbose build details of an application and to help understand make file configuration and processing, consider using the command line arguments: bmake +avilC YourAppName.mke > buildoutput.txt.