I don't quite understand the problem. If one build target is "Windows Debug" and the other is "Windows Release", they certainly both have their own set of options. If you want some global overall options, you can put them into the project's options section. For different paths under different operating systems, use environment variables or global user variables whenever you reference a path. If you need special compiler or linker flags for some platform, you can even put these into an ev or guv.
If you want the debug and release version to have the same source files and options, simply make one a copy of the other. If one needs other source files, libraries etc., change them for this particular target. When you add a new file to the existing project, you are prompted with the available build targets, and you have the option "add to all". No real need for virtual build targets here, no manual doing things several times anyway.
Virtual build targets are good if you have several independent components and want to save compile time by not rebuilding everything every time. One might be tempted to build "Windows Debug" and "Windows Release" at the same time using a virtual build target, but honestly that's a somewhat silly idea. Nobody would really want to do that, realistically.
As for Linux or MacOS builds, I would personally put these into a different project file as it's less cluttered, but of course you can leave them in there either way.
