I think the question is a little ambiguous. If the question is about hardware addresses of the real and complex parts, then I think the answer is no for the above reason, the language abstracts away things like hardware addresses. But if by “adjacent” you mean storage locations, then I think the answer is yes. That is the abstraction we are talking about here from hardware addresses to the abstract concept of storage sequences defined in the standard.
The 7.4.3.3 (1) part above refers to the “first” and “second” real values. I think that does refer to the abstract storage sequence, but not to the hardware addresses. Just to give an example of the difference, a compiler might choose to address everything backwards, so that the low array index values refer to high hardware addresses and visa versa. In this case the “first” value (higher hardware address) would correspond to the low array index, while the “second” value (lower hardware address) would correspond to the next storage unit and to the higher array index. There could also be segmented address spaces, for example where each abstract storage unit corresponds to two separate hardware addresses taken together in some (as far as the standard is concerned) arbitrary and unspecified way.
19.5.3.2 (2) (2) refers to “two contiguous storage units”. That refers to the abstract storage sequence, not to the hardware addresses. The hardware addresses could be and (for multibyte entities) usually are not contiguous, and I believe they could even be switched w.r.t. high and low values, they could have padding bits, and so on.
19.6.5 (13+14) says that you can define a complex entity by defining separately the two real parts. You can define the two real parts in different ways, and as far as I know, they are all allowed by the standard. For example, two scalar real entities in a common block can be storage sequence associated to a single complex entity, or a real array could be storage sequence associated with a complex entity, and so on. I don’t think an internal polar coordinate representation can be coerced into this abstract model.
BTW, all of this also applies to character sequence associations. You can define a long string by defining its parts through storage sequence association, but the storage sequence associations are abstracted away from the actual hardware addresses. To give an actual example, the old Cray hardware was not byte addressable, its hardware addresses referred to 64-bit words. In the cft77 compiler, a character storage unit was 8 bits, and there were 8 characters stored in each word. The abstract character array indexes and the substring indexes then required both a word address and an offset within the word. At the abstract fortran index level, everything worked just fine, all of those details were hidden and you never really needed to know all the screwy stuff going on with the hardware addresses.
I must admit that I was a little surprised in this discussion to realize that c_f_pointer() does not allow these same kind of associations. This is all nailed down pretty solidly, and I don’t see how it could not work in practice, so it seems like the standard should make the appropriate type/kind exceptions on behalf of the programmers who might want to depend on this feature of storage sequence association. Presently, as noted above, the programmer is on his own to manage the storage sequence associations (e.g. for noncontiguous arrays).