>>I can only guess. Maybe it's because Adel() alone is not sufficient, you must re-dimension the array afterwards.
>
>It does what it does - deletes elements and shifts down all the elements above, initializing the last element/row of the array to .f. ... and now it's up to the programmer to decide what to do with that. Redimensioning to lose those trailing elements is one option; keeping a variable with last usable element/row is another (in cases when we may expect an ains() soon, this avoids multiple redimensioning); checking for element type is yet another. The 2nd option, I think, is the reason why adel() and ains() don't automatically redimension the array - it takes some time to do so, and it may actually be redundant.
>
>Sometimes I wonder why Fox does some things and then the answer "because it was faster that way on a 286" pops up.

And of course one needs to carefully read the documentation. While we might be aware of when we delete rows/elements in an array and all the trailing items are "shifted," the same does NOT occur when you delete a column in a 2-dimensional array.
https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/b26a3deh%28v%3dvs.71%29
in the Remarks: "... If you delete a column, values of the elements in the deleted column are set to False (.F.), but trailing elements are not moved."

Update: just tried out quick experiment

dimension afoo[3,3]
afoo[1]="one"
afoo[2]="two"
afoo[3]="three"
afoo[4]="four"
afoo[5]="five"
afoo[6]="six"
afoo[7]="seven"
afoo[8]="eight"
afoo[9]="nine"
display variable afoo
list memory like afoo
? ains(afoo,2,2)
list memory like afoo
? adel(afoo,2,2)
list memory like afoo

the results do seem to indicate that when you use ADEL() to delete a column, the trailing elements of each row *are* shifted.