VS2017 和 VS2015 应用程序与 dll 之间的官方二进制不兼容性是否准确？

TL;DR- MS 文档指出 VS2015 和 VS2017 库之间的二进制兼容性是one-way，虽然我认为这必然是双向的。问题在哪里？

首先，背景：

• 任何 MSVC++ 构建的库都是正式二进制兼容VS2015 和 VS2017 之间。
• 具体来说，您可以将 VS2015 C++ 应用程序与 2017 年起的 MSVCRT140 版本一起使用。（VCRedist 向后兼容)
• The 官方文档网站陈述一个令人困惑的限制.

背景/相关问题：

• Visual-C++-2017 二进制文件与 VC++-2015 兼容吗？
• 关于“Visual Studio 2015 和 Visual Studio 2017 之间的二进制兼容性”的问题
• VS2017和VS2015之间的二进制兼容性

我发现令人困惑的限制是：

此规则有两个例外。在这些情况下，不保证二进制兼容性：

...

食用时使用版本更高的工具集构建的库比用于编译和链接应用程序的工具集。例如，使用编译器版本 19.12 编译和链接的程序可以使用使用 19.0 到 19.12 编译的库。

恕我直言，这个警告在技术上既草率又令人困惑。技术原因是什么？

我说它很草率，因为它不完整，因为可执行文件和 DLL 之间的接口非常对称，但这个项目符号只涵盖“应用程序”。

具体来说，and假设所有模块都是针对动态 CRT 版本构建的，并且此动态 CRT 版本是可用的最新版本，我看到以下组合，其中二进制兼容性是一个问题：

• my_2017.exe <-> my_2015.dll——貌似支持
• my_2015.exe <-> my_2017.dll——貌似不支持
• my_2017.exe <-> my_2015.dll <-> my_2017_x.dll-- 现在怎么办，这个受支持的 DLL 是在哪个“方向”？

由于二进制兼容 - 纯粹从二进制/接口的角度来看 -必须双向运行，我不太明白我们在哪里突然会遇到不兼容性：API 调用可以双向（回调等），对象“移动”双向，甚至 DLL 加载的顺序也可以混合。

恕我直言，这是很重要的一点，因为它意味着二进制兼容性就像声明的那样 is severly有限的：

• 如果我的应用程序想要消耗任何VC14*编译库，我“正式”仍然必须确保我的应用程序是使用“最新版本”构建的。
• 另一方面，如果不构建“应用程序”，但有一个 DLL，我似乎可以使用任何其他应用程序VC14*和DLL可以兼容吗？
• 有了 VCRedist，我们就有了exactly看似的情况不支持的，即我们是allowed从 2015 年的应用程序使用 VC2017 库（本例中为 CRT）！

Question

那么，为什么（！）会受到这样的限制，以及它与 dll 间依赖关系以及反向（！）CRT-dll 版本要求有何关系。

微软此后更新了他们的文档，当前版本的相关部分https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 reads:

Visual Studio 2015 和 Visual Studio 2019 之间的 C++ 二进制兼容性

...

当您混合使用不同受支持版本的 MSVC 工具集构建的二进制文件时， 您的应用程序运行所在的 Visual C++ 可再发行组件不能太旧 比使用的任何工具集版本 构建您的应用程序或其使用的任何库。

差异位于https://github.com/MicrosoftDocs/cpp-docs/commit/a505dccfb31eb49c2ffece4dabd24a0a61b1fcb3#diff-d488b4c71be450b2a39cdce495c229bf

没有直接的 GitHub/MS-Docs 问题，但这个限制更有意义：它只是讨论了兼容性要求可再发行，并且要求 VC 运行时版本至少与正在使用的最新模块一样最新。

当然，这是有道理的，因为这不仅仅是纯粹的二进制兼容性。

当然，我在问题中所说的仍然有效：任何（旧的）VS2015应用程序必须与（新的）VS2019可再发行组件兼容，所以我猜VCRedist-VC14.0曾经公开的所有界面表面都应该是二进制兼容的。