#include <iostream>
#define Head <iostream>
# if __has_include(Head)
#define Pn 0
#endif 

#ifndef Pn
#define Pn 1
#endif
int main(){
   std::cout<< Pn;
}

Consider this example, GCC and Clang both print 0. But rather, as per [cpp.cond] p4

The header or source file identified by the parenthesized preprocessing token sequence in each contained has-include-expression is searched for as if that preprocessing token sequence were the pp-tokens in a #include directive, except that no further macro expansion is performed.

A hazy point(also, see https://stackoverflow.com/questions/70617486/condition-inclusion-through-has-include-expression-and-has-attribute-expression) is that in [cpp.cond] p3.

The second form of has-include-expression is considered only if the first form does not match, in which case the preprocessing tokens are processed just as in normal text.

When we intend to say macro replacement would happen somewhere, we usually say "just as in normal text". The first form of has-include-expression is that

__has_­include ( header-name )

which can be further divided to

• __has_­include ( < h-char-sequence > )
• __has_­include ( " q-char-sequence " )

The second form is

__has_­include ( header-name-tokens )

which also can be further divided to

• __has_­include ( string-literal )
• __has_­include( < h-pp-tokens > )

I would say, even if [cpp.cond] p3 was intent to phrase that a macro-replacement would occur, it can only occur in the bold form. Since we have implied that the identifier-like sequences cannot be replaced in a string-literal [cpp.replace.footnote] 137

Since, by macro-replacement time, all character-literals and string-literals are preprocessing tokens, not sequences possibly containing identifier-like subsequences (see [lex.phases], translation phases), they are never scanned for macro names or parameters.

Back to this example, Head conforms to none of the above forms. The macro-expanded shouldn't occur for Head even if macro-expanded could be performed for has-include-expression.