Please see this minimum example

char const* v = 0;
int* identifier = (int*)v;

As per [expr.cast#4], the conversion should undergo that as specified below

The conversions performed by

• [...]
• a reinterpret_­cast followed by a const_­cast

can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply, ...

In other words, the conversion should firstly use reinterpret_­cast, after that, const_­cast is used to produce the ultimate result.

As per [expr.reinterpret.cast#7]

An object pointer can be explicitly converted to an object pointer of a different type.60 When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_­cast<cv T*>(static_­cast<cv void*>(v)).

The source type is "pointer to const char" while the destination type is "pointer to int", hence the middle result produced by reinterpret_­cast is equivalent to static_­cast<int*>(static_­cast<void*>(v)) since the cv is empty.

As per [expr.static.cast#1] or [conv.ptr#2]

The static_­cast operator shall not cast away constness ([expr.const.cast]).

A prvalue of type “pointer to cv T”, where T is an object type, can be converted to a prvalue of type “pointer to cv void”. The pointer value ([basic.compound]) is unchanged by this conversion.

In either rule, the cv-qualification of the source type shall not be discarded from the destination type. In the nested conversion of the above conversion, namely static_­cast<void*>(v), the destination type is void* while the source type is char const*, this conversion discards the const qualification, it seems that "The same semantic restrictions and behaviors apply" does not intend to give the privileged that discards cv-qualification to any conversion produced by explicit type conversion.

However, the example is accepted by all major implementations, it's reasonable to be considered well-formed. Despite that, it cannot be well interpreted by the standard.