sunslayer, there is no distinction to be drawn between one dimensional and multi-dimensional arrays; both of these would be implemented in mIRC by way of naming elements uniquely using commands such as /set %array[0][0] or /hadd -m array [0][0] value. by the way, i'm sure you'll agree that defining and referencing variables named %array[X] or %array[X][Y][Z] does not require this snippet, and this snippet just provides extra higher level functions for such array management :P

if execution time is an issue then you're certainly right: mIRC's hash tables are faster for any reasonably sized data set. but, of course, you wouldn't want to use a scripted interface (these pseudo-arrays) for simple data management if that were the case. so, while this snippet may not be geared towards those who wish to create quick and optimal code, it can provide various luxuries to scripters who wish to use more intuitive array syntax.

as for array support in mIRC, it sounds like a good idea in principle but really it wouldn't be something that is likely to add any significant benefit - even to those who purport to need it! recall that mIRC script is typeless, thus the creation of int or char arrays at the script level is not feasible. an array in mSL would necessarily be an array of (wide character) strings.

ignoring multiple dimensions for the moment, suppose /amake , /aadd [value] and $aget(, ) were introduced to manipulate and return information on these arrays. notice that this resembles the syntax for mIRC's hash tables. while our value would ordinarily pass through a hash function to yield an integer through which the low-level array can be accessed randomly, here it needs to pass through a function resembling atoi() for wide character strings to yield that same integer - i would imagine the difference between these operations to be negligible, especially at the scripter's level. and yes, while a hash table is populated by linked lists that need to be traversed, this again is an operation that none but the most pedantic scripter is likely to complain about.

so basically, a native interface for arrays in mIRC script would offer so little with regards to performance gain that we shouldn't expect to find it in the client any time soon.