I don't think this is the only way the compiler has. If px was not initialized with a value, it is nil by default if declared as a global variable, or it holds some random value if declared as a local variable. The compiler could issue a hint or warning for the first case, and error for the second case.
The problem is as follows, for the compiler to use the value assigned to px or any pointer for that matter, it has to dereference px at compile time. dereferencing a pointer is a runtime operation, not a compile time one.
The situation we have today is the confusing one. The compiler accepted @x and refused an equal value because it came from a variable px that hold the same value. This question is an example.
It's not confusing because in one case it's a constant (@x) and in the other it's a variable (px^).
The array is initialized with constants in both cases. The value px holds at the time of initialization is a constant. The compiler could alert the programmer when this variable is not initialized.
It isn't initialized with constants in both cases. In the case of px, it is initialized with the value of a variable and no compiler is going to dereference the value of a pointer at compile time even if the value of the pointer happens to be known.
Other than design decision, I don't see what makes it impossible.
There are definitely some cases where it would be impossible, e.g, when the pointer isn't initialized. At runtime, if a programmer dereferences a nil pointer, that causes an access violation. To have a compiler dereference pointers at compile time, it would have to interpret the code as it is compiling because if pointer dereferencing is allowed at compile time then it has to support dereference chains where one pointer has the value of another which has the value of another and so on until it finds the "root pointer" that has (hopefully) been assigned a value. That's a nightmare for a compiler (not to mention for the programmer who has to write that compiler.)
In addition to the above, there is a semantic problem in allowing an array element to be a variable. The statement:
arr: ArrayOfPReal = (@x, px);
states that arr[1] is px, therefore whatever value px has at anytime should also be the value of arr[1]. IOW, at runtime when px is assigned a new value then arr[1] should have that same value since arr[1] is px. That's the semantic meaning of that declaration.
Maybe it is possible to implement it but, the number of difficult problems and complications it creates is significant.