Why does VS not define the alternative tokens for logical operators?

You ask about the rationale. Here's one possible reason, not necessarily the one that most influenced the Visual C++ team:

1. Those are valid identifiers in C.
2. Microsoft's recommendation has long been to use C++ mode for both C and C++ code, rather than maintaining a modern C compiler.
3. Valid C code using these as identifiers would gratuitously break if they were compiled as keywords.
4. People trying to write portable C++ are mostly using /permissive- or /Za for maximum conformance anyway, which will cause these to be treated as keywords.
5. The workaround to treat them as keywords in /Ze by including a header file is easy and portable. (G++'s workaround -fno-operator-names isn't bad either, but putting the option in the source code rather than the build system is somewhat nicer.)

VS is nonconforming. This is old news.

To use alternative tokens, include the <ciso646> header. According to the standard, including this header is supposed to have no effect in C++. However, you do need it in VS. So it's safe to just include it always, whenever there is any chance that you might be compiling with VS.

Formally, these keywords are implemented and are supported intrinsically by the compiler without including any headers. However, for that you have to compile your source code in "more standard" mode of that C++ compiler, which means using the /Za option.

By intent, the /Za option is supposed to "disable compiler extensions". Of course, not supporting something that is supposed to be there in a compliant compiler cannot be formally qualified as a "compiler extension". Yet, that just the way things currently are.

Modern Visual Studio (or rather, MSVC) does support alternative tokens; however, it does so only in standards conformance mode. This mode comes with lots of goodies, so it should always be used.

To enable it, pass /permissive- to the compiler.

The answer below is obsolete. This is now supported, see above!

Previously, Microsoft’s position was¹ that

#include of <iso646.h> (or ciso646) is how we support these keywords

And because “nobody” (before me, in 2007) ever requested this.

¹ link currently defunct; left here for archival purpose.

(contemporary update)

I made a small test: A New "Windows Desktop Application" Project. The IDE (Visual Studio 2017 15.7.5) sets, by default, the following C++ language conformance settings: /permissive- /Zc:wchar_t /Zc:forScope /Zc:inline. In addition, I set the C++ Language Standard to ISO C++ /Latest draft (currently up to C++17). In addition, I added, in the main(), the following 2 lines:

bool a, b, c;

a = b and c;

It compiles the text-forms of the logical operators successfully. But when I altered the IDE Conformance mode to No (=> without /permissive-) and re-compile, the compiler marks: "error C2065: 'and': undeclared identifier".

By default, the /permissive- compiler option is set in new projects created by Visual Studio 2017 version 15.5 (December 2017) and later versions. It is not set by default in earlier versions. So if someone created a project prior to version 15.5 and by the time update the IDE to the latest version, still it required to set in the project this compiler option manually.

The /Ze compiler option, which is on by default, enables Microsoft extensions. The /Ze option is deprecated because its behavior is on by default. MSDN recommends to use the /Zc (Conformance) compiler options to control specific language extension features.