>>515
前提が全く噛み合ってない。
おそらく現場で C++ の使い方は学んだベテランだが言語仕様や設計論はあまり知らないタイプ。
昔からデバッグを何もかもブレークポイントでやってきた現場のテイストを感じる。
しきりに「経験」を繰り返しているのは自分の論が経験則でしかなく合理的に説明できないからだろ。
私はプロではないがログ API にストリームを被せるくらいのことはしたことはある。

私は Visual Studio のことは知らんから具体的な操作は分からんが、オーバーロード解決がどうなったなんてコンパイルするすらしなくてもインテリセンスの機能で表示できるはずだ。
(少なくとも VSCode では適切なアドオンを入れていれば出来るし、 Visual Studio がそれより劣るということはあるまい。)
ツールチェインが信頼できなくて最悪の場合に実際にどうなっているかを確認するにはブレークポイントが役立つこともあるが……最適化と組み合わさると意図したところにブレークポイントを置けないなどのトラブルは起こりがちでソースレベルデバッグではむしろブレークポイントのほうが信用できない。

テンプレート (std::print) の展開結果を確認するよりはオーバーロードの選択結果を確認するほうが楽というのはわからんでもないが、そんな確認が必要になることが頻繁にあるのなら開発体制のどこかが間違えていると思う。

念のために注記しておくが、現時点で std::print 系のライブラリの実装が充分にこなれていない環境もあるのは事実だ。
何せ新しいのでやむをえない現実があることは否定しない。
あくまでも >>451 が開発者用ログ機能としては << で繋げていくやり方がこれからも生き残るというニュアンスなことに対して原理的には理想的ではないと反論している。
現時点での実装の細部の不備はもとより論点ではない。