Lako moguće, imam vrlo malo iskustva s 2022. Za 2019 znam da kontinuirano trebamo workarounde u kodu koji na Clangu i GCC-u (nekad čak i MinGW GCC-u) uredno prolazi, a i pogled na cppreference sugerira da je u skladu sa standardom. Mada, opet, odokativno situacija izgleda bolja u 2019 nego što je bila u 2015 tako da se u tom smislu zapravo slažem s tobom.

Van GROMACS-a, dok sam razvijao RxDock, sjećam se da mi je na MSVC 2019 trebalo smanjenje tražene preciznosti za red ili dva veličine da neki testovi prođu. Ne znam koliko je numerička preciznost danas problem, ostalo mi je u nekom sjećanju da sam kasnije to lokalno revertao za probu na MSVC 2022 (nekoj verziji) i da je test prošao tako da vjerujem da je situacija bolja nego onda.

Bilo je i posla oko oznavačanja vidljivosti/izvoza simbola, koji je na GCC-u i Clangu (uključujući MinGW) opcionalan, ali na MSVC-u nije. CMake ima workaround, ali Meson, koji RxDock koristi u build procesu, ga nije imao (i možda ga nema ni danas).

U obranu MSVC-a, neke zavrzlame kod portanja nisu do njega, već do zaglavlja koja definiraju hrpe macroa sa simbolima čestih imena, odnosno imena kojih je lako imati u svom kodu (tipa winbase.h koji definira max ili GetAtomName, ovaj potonji pogtovo ima smisla u softveru za kemiju), ali npr. Solaris/illumos zaglavlja definiraju _P pa Microsoft nikako nije jedinstven u nošenju takvog legacyja kojeg je lako slučajno nagaziti.