I've got 15.6.7 and it set __AVX2__ for me, but ONLY at compile time.  Intellisense appears confused and is greying out my #ifdef __AVX2__ block.  The code inside the #ifdef actually ran though.

I've always done it manually .. detected CPU support at runtime with something like cpuid, and had multiple code paths for bottleneck code for different processors (it's kind of fun writing SIMD code!), I would be interested to know how good the compilers are at converting code to use SIMD themselves now.

Not really answering your question but ... If you were relying on the compiler to do the SIMD conversion, and you wanted to be lazy, you could also compile 2 / 3 different DLLs with different compile options and select at runtime? This is one of the suggestions here, which discusses some of the problems:

https://randomascii.wordpress.com/2016/12/05/vc-archavx-option-unsafe-at-any-speed/

Another possibility might be to look at the assembly generated for bottleneck areas, and either just copy this entirely, or use it as the basis for your own, or help identify areas where you could make it easier for the compiler to make it SIMD, as it is highly dependent on the data layout (caveat, I've not delved into examining compiler generated SIMD, I don't know how practical this is).

While I understand wanting to get the latest and greatest CPU support, I'd be wary of it for most projects.

Targeting x64 enables many optimizations and benefits not accessible in 32-bit versions, and the Steam survey shows about 2% still using 32-bit Windows. 

For AVX2, while it is certainly nice for the compiler to take advantage of bigger registers and parallel optimizations, in practice the gain is minimal since that's not the typical bottleneck. The Steam survey says AVX (original, not 2) has about 89% adoption rate, and they don't list AVX2. 

Unless you have a specific algorithm you know is a bottleneck and you know needs to be implemented using AVX2 calls, I wouldn't bother with it. You probably have many more features you could pack into the game in the time it would take to hand-roll some code that takes advantage of the specific processor feature.

As a sidenote, i would not recommend to rely on the automatic vectorization of compilers. I did a bunch of test with various ones, gcc, g++, MSVC2015, MSVC2017(default and clang toolchain) and yes it does work, buuut breaks quite easily. So if you want to have that for speed, you should use intrinsics. Also, at least MSVC generated several codepaths with cpuid checks but only on the auto vectorized code.

You can detect support from CPUID and implement the AVX2 variant by detection if you really want to. If your compiler has multi-versioning support this is really easy (gcc, clang), otherwise I'm sure there are workarounds.