Совместимость во время выполнения для упаковки библиотеки

Я хочу упаковать библиотеку как нативный пакет NuGet. Этот вопрос не является специфическим для способа, которым распространяются упакованные lib / dll / pdb / include; но чтобы быть конкретным, я смотрю на CoApp скрипты (Хотелось бы, чтобы было что-то лучшее, на что я мог бы ссылаться), и у меня сложилось впечатление, что существует слишком много различных целей сборки, полученных комбинаторно. Я пытаюсь придумать более или менее минимальный набор целей, который может использоваться приложениями, которые зависят от пакета. Существуют следующие в основном ортогональные оси для целей сборки:

1. 32 бит против 64 бит. Очевидно, это законно.
2. Динамические и статические сборки. Это тоже разумно.
3. Отладка против выпуска сборки. Это также имеет смысл, так как отладочные сборки ссылаются на время выполнения отладки (libcmtd.lib или же msvcdrtd.lib) и сборки выпуска ссылаются на статическую среду выполнения (libcmtd.lib или же msvcdrtd.lib). Имеет смысл включить их, чтобы избежать конфликта библиотек по умолчанию.

Выше, безусловно, хорошие оси. Следующий вопрос сомнителен, хотя присутствует во многих примерах:

4. _cdecl против _stdcall против __fastcall против __thiscall, Я думаю, что это имеет мало смысла. Соглашения о вызовах будут поддерживаться для этой конкретной библиотеки независимо от других связанных библиотек. Кроме того, переменные аргументы предназначены для _cdecl только в Win32, а также 64-битные соглашения о вызовах иначе все равно. Я понимаю, что все, что я выберу, будет делать, пока заголовочные файлы объявляют соглашения о вызовах, совместимые с платформой. В любом случае библиотеки времени выполнения Microsoft не предоставляются для различных соглашений о вызовах.

И следующий я не уверен, как справиться. Опять же, примеры объявляют

5. библиотеки строятся разными наборы инструментов, которые поставляются с различными версиями Visual Studio: от v100 (v10.0, VS 2010) до vs140 (v14.0, VS 2015). Мой главный вопрос: насколько совместимы библиотеки времени выполнения для разных библиотек Visual C ++? Проблема здесь в том, что мы используем и другие наборы инструментов (например, Intel C ++), и они обычно не имеют соответствующих случаев упаковки в CoApp, будучи совместимыми со средами выполнения Microsoft.

Я хочу избежать упаковки для определенного набора инструментов. Насколько это возможно, если код компилируется с самой старой версией, а также не использует какие-либо более новые функции времени выполнения (например, v110 является самой низкой поддерживаемой версией)? Я беспокоюсь о двух основных вещах (извините, здесь начинается еще один нумерованный список):

1. Если я скомпилирую статическую библиотеку с VS 2012 (при условии соответствия битности, статичности и отладки), я смогу связываться с ней в VS2013 (ее libcmt[d].lib)?
2. Могу ли я ссылаться на него в тех же условиях в VS2010?
3. Те же два вопроса, но если говорить об общей среде выполнения DLL?
4. Те же вопросы, но с учетом определенных библиотек времени выполнения исключений, которые могут быть выданы библиотекой: будет e. г. std исключения должны быть совместимы вверх и вниз по цепочке версий компиляторов, если я скомпилирую библиотеку с включенным RTTI?

В целом, существует ли матрица совместимости во время выполнения, предоставляемая Microsoft?

И если какие-то другие пункты нумерованного списка, я бы тоже хотел это услышать.