The unicode/multi-byte/ansi one (_UNICODE, _MBCS, or lack of either respectively) affects things that could or could not change underlying APIs.
Primarily this would involve around the TCHAR type, which gets defined specifically to wchar_t (unicode) or to char (multibyte/ansi). the _T/_TEXT macros and the _tcs<x> functions all get defined similarly too, as well as windows APIs getting defined going to A or W suffixed versions, but these all should primarily be internal and not affect externally facing APIs or limit usage thereof.
But since there is the chance it can affect things depending on the code, it should probably be modeled and tracked.
Similarly, the /Z:wchar_t(-) also affects things similarly for whether wchar_t is a native type or is a typedef to a short. This discrepancy makes C++ decorations incompatible, but C lacks that, so not an issue there…
There’s quite a large amount of flags/options for Visual Studio that drives the behavior that utilizing code need to be aware of. I’ve not looked at gradle’s IDE models for Visual Studio yet, but it seems like these are probably starting to pop up there too.
Because there is quite a large discrepancy between Visual Studio (and derived) and GCC (and derived) in compiler options and “metadata that needs tracking”, I’m wondering if it would be more convenient to have DSL options/configurations that are specific to each of them…
But, given the drastic differences between Visual Studio and GCC, usually if you stick to VS’isms or GCC’isms like things mentioned above in exposed APIs, there’ll be lots of issues in trying to (start) using the other compiler variety…