Undocumented node_modules/@types fallback strategy for classic module resolution

I'm using TypeScript 2.7.2 with MSBuild 15.9.21.664

A fallback was added to classic module resolution to resolve modules using node_modules/@types in this PR https://github.com/Microsoft/TypeScript/pull/11147
Going purely from the Module Resolution section of the handbook, I would have expected this behaviour only when using node module resolution.

This is undocumented behavior is an issue because the fallback will override any ambient module declarations in the resolution process.

To give some context, I have a ASP.NET MVC project that uses MSBuild to compile TypeScript. This project takes advantage of some TypeScript files in a separate NPM project located up a few directions on in the File system by using the following csproj syntax:

<TypeScriptCompile Include="..\..\external-typescript-project\src\Cat.ts">
     <Link>Scripts\app\Cat.ts</Link>
</TypeScriptCompile>

When MSBuild shells out to tsc it does so like tsc "..\..\external-project\src\Cat.ts".

So far so good, except if both projects share the same TypeScript definition dependency i.e. if both the MVC project and external NPM project have a TypeScript definition for jQuery, the "....\external-typescript-project\node_modules@types\jquery.index.d.ts" is used in preference to the MVC project's ambient jQuery module declaration.
If I manually delete the "....\external-typescript-files\node_modules@types\jquery.index.d.ts" file the MVC project gets the correct ambient module declaration.

In an ideal world I'd disable MSBuild triggering the compilation using <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> and manage TypeScript definition dependencies using NPM with module resolution "node", but the entire project relies on ambient module declaration files in a custom ".\typescript-definitions" folder which gets passed to the TypeScript compiler i.e. tsc "..\..\external-project\src\Cat.ts" "typescript-definitions\jquery\index.d.ts", so it would be a tricky migration.

My understanding is path mapping would solve the issue, but unfortunately this isn't supported by MSBuild. I would like the ability to opt-out of falling back to node_modules/@typings when using classic module resolution, or at the very minimum this behaviour could be documented.

Start with the Module Resolution section of the TypeScript handbook and PR #11147, then compare their documented behavior with the classic-resolution fallback described here. Done means the node_modules/@types fallback is accurately documented, or the issue is narrowed to a specific opt-out requirement.