>>The last column will be .f., but the rest of the elements won't move correctly. You'd expect that the old 6th element (the 1st element of the 2nd row before redimensioning) would now be the 7th element, but no - it's now .f., and the a(2,1) doesn't contain a filename, it contains a length. Check in the debugger. When you do ains() without the third parameter, all the elements below the starting position shift nCol positions down, so if you do aIns(a,4), you get a(4,1) to a(4,5) as .f., a(5,1) contains what was in a(4,1) etc. Doesn't work when inserting a column.
>
>When applied to two-dimensional array with column insert option, elements don't "shift" from one row to another -- elements at the end of the row "fall off" the end rather than "wrapping" into the following row. The workaround would be use AINS() with the array as if it was a one-dimensional and insert the desired item one (logical) row at a time (using AELEMENT() to get the proper element number from the row, column subscripts). That should prevent the loss of the data and "realign" the data into the proper columns.

IOW, aIns() has a bug when inserting columns and we should roll our own.

Not that I ever needed it... just got a question from a friend (kind of apprentice... for about 11 years now) and just had to take a look. This is how weird threads start.