It seems odd to include predefined macros at the driver, which AFAIK is just a bridge to the frontend's command-line interface. OTOH, there is other precedence for doing this - during clang-cl's argument processing. So I don't have a strong opinion here.
Are you sure this shouldn't also define _UNICODE? looks Hmm... GCC doesn't define it. I wonder if we should anyway. A user who set -municode may also be using <tchar.h>, and thus may want those macros set to their Unicode counterparts.
I actually believe this is supposed to have one other effect: it sets the entry point to wmainCRTStartup()/wWinMainCRTStartup(), making the user entry point wmain()/wWinMain(), which take wide arguments:
int wmain(int argc, wchar_t **argv); int WINAPI wWinMain(HINSTANCE hinst, HINSTANCE hinstPrev, LPWSTR pwszCmdLine, int nCmdShow);
But that's a link-time effect. I believe it has no bearing on @rnk's comment.
...Actually, that suggests that we may want to warn if the user defines main() or WinMain() instead of their Unicode counterparts when -municode is given--which means we may want to pass it to the frontend after all.
It already does this; lld (and I guess ld.bfd as well) detect the entry point based on what symbols are available. But this flag switches between passing crt2.o and crt2u.o to the linker, essentially forcing an undefined reference to either main or wmain.