My understanding:
It is not dereferencing, but converting.
Yes, that's correct. The code is converting the "pointer to array of characters" into a shortstring with the same characters.
"p" will not be dereferenced. If it was, it would pass a single char too Foo. But it passes an entire (null terminated) string.
Yes, that's correct too.
Whenever a pchar is used, where a string would be required, it is converted.
That is what leads to "strange things". In a strongly typed language a "pointer to char" cannot be compared to a "char". The types don't match (C++ won't accept it and quite likely C won't either.) The fact that such a comparison works gives the impression that either the "pointer to char" is being automatically dereferenced (which would make the types match) or, what C/C++ do, compare the value of the pointer to the address of the character constant (saved in a read-only section by the compiler) or, lastly what FPC is doing, converting a "pointer to char" into a shortstring and comparing the shortstrings - which is a strange thing to do since the compiler can't always know what p points to looks like (I guess it will just accumulate characters into a shortstring until it finds a null.)
Probably lucky that it does not cause a crash, as your array of char has no null termination.
In the example, I chose to add a counter to prevent going out of bounds but, your point is valid. I definitely wouldn't have the array nor the code that way in a real program.
This also explains why it is never equal to '/'.
Because it is a string starting with '/abcd', continuing to a null byte.
Actually, it's comparing '/' to '1234567890/abcd', as you stated, that will definitely never be equal.
I guess, that's just the way FPC does it. It opens the door to unexpected problems when the programmer missed typing the "^", which is how I "bumped" into this situation. That reminds me of C, one typo and good luck... you'll need it.