解決していたら申し訳ないんですが…
msvcのlibcはちょっとややこしいので、基本的なことから説明します。以下はmsvcを念頭に置いています。
1 そもそも.libファイルには何が記録されているか。
libファイルには大別すると、静的ライブラリとインポートライブラリの2つの種類があります。
それで、静的ライブラリは、ソースファイルをコンパイルすると、ソースファイルごとに、コンパイル後のバイナリとして.objファイルが出力されますが、この.objファイルを一つのファイルにアーカイブしたものです。要するに、リンク前のコンパイル済みバイナリの集積体です。
そのため、静的ライブラリの内容は、主にコンパイル済みバイナリコード(関数の実体)を集積したものです。デバッグ情報とかも記録されてはいるのですが、主な存在意義は、関数の実体の集積です。
そのため、リンク時にリンカーの入力ファイルにすることで、libファイル内に実体がある関数を引っ張ってきてexeなどに書き込めるというわけです(静的リンク)。
一方、dllと同名(理論的にはそうではないものも作れるんですが、普通は同名です)のlibファイルは、インポートライブラリと呼ばれる種類のライブラリで、大雑把に言えば、関数の実体ではなく、dll内の関数の情報リストを記録しているものです。
ですので、インポートライブラリをリンカーの入力ファイルにした場合、リンカーは、関数の実体が記録されているdllと、そのdll内での関数の場所の識別情報をexeに書き込みます。そして、exeは、実行時に自身に書き込まれたその情報を基に、dllから関数を呼び出せる(動的リンク)というわけです。
つまり、同じ.libファイルでも、静的ライブラリとインポートライブラリでは、記録されている内容が全く異なるということになります。vulkan-1.lib や d3d12.lib は、vulkan-1.dllやd3d12.dllのためのインポートライブラリです。
2 msvc で静的ライブラリを作成するとどうなるか?(libc問題)
msvcの.objファイルは、ライブラリなどのリンク情報を保持できる( #pragma comment(lib, "shlwapi.lib") はこの情報を.objファイルに書き込むためのもの)のですが、デフォルトでは、コンパイル時にC/C++ランタイムライブラリ(libc)のリンク情報を、.objファイルに書き込みます。
そのうえで、msvcのC/C++ランタイムライブラリ(libc)は、Release/Debugの別でABIが大きく異なっている(バイナリの内容が異なる)ため、例えば、.obj側がDebugの状態だと、Releaseのlibcとリンクできる保証がありません(リンカーがDebugモードで使われるlibc関数を探しているのに、Releaseモードのlibc関数しかないためにリンクすべき関数が見つからないとかがざらです)。
そのため、.objファイルの集積体となる.libも、Debug/Releaseのどちらかに固定されてしまうというわけです
ちなみにですが、msvcのlibcは、Debug/Releaseの別以外にも、libc自身のリンクについて、静的/動的のどちらにするかというのでもバイナリが分かれており、これも一致させる必要があります。
3 Release/Debugで共用できる静的ライブラリとは?
それでは、msvcで、Release/Debugで共用できる静的ライブラリとはどのような内容なのかということですが、要するに、「libcのリンク情報を一切含まず、かつ、libcへの依存が全く存在しないライブラリ」ということになります。そのためには、C/C++の標準ライブラリを一切呼ばず、C/C++の言語機能のうち、ランタイムサポートを要するもの(例外とか実行時型情報とか)を全く使わずにコードを書き、コンパイルオプションとして"/Zl"を指定すればそうなります。
そして、YUKI_DAYOさんが引用されている、「
Debug版とRelease版で同じLibファイルにする方法」の egtraさんの
回答がまさにその内容となっているわけです。
ただし、面倒な割にデメリットが大きいですね。