Because they are different kinds of constructs.
A type name is only relevant to identify a type during compilation. As such it is relevant when it follows the
type keyword as well as after
as. Besides that it is never used (if variable X is of type T, this will just be a numeric reference held by the pre-/compiler; it's name is not used beyond declarations).
Likewise the array names are held in a different table. The same goes for variables, functions and subroutines I suppose. As long as they occur in different sections, a shared name is without consequence. However it introduces ambiguity if used in any place where constructs of more than one kind, where a identifier name is shared, can be used. For example as argument to a function that can take both an integer (variable) or an array. I'm uncertain how many such constructs there actually are in DBPro though.
I suppose the "if exit" may translate into "if exit()", which is why that fails. However the exit function has no return value (and quite frankly isn't even a function but rather a loop control). Or maybe it doesn't work because the if clause parsing actually rules out any reserved words (such as
exit) to prevent ambiguity and strange bugs. If so, all functions / constructs should however, but it seems they don't. Sloppy compiler mayhap?
"Why do programmers get Halloween and Christmas mixed up?" Because Oct(31) = Dec(25)
