二次元配列に対応できた。処理速度を簡単なベンチマークで試したところ、本家版 String Tokenizer よりも 2.5 倍程度処理速度が速い。
参考：String Tokenize 機能、速度比較 | CF2.5 ガイド. 参考：新エクステに含まれる機能について（メモ） | CF2.5 ガイド.
本家版はメモリ管理に大きな問題がある。 prester 版ではメモリに関しては比較にならないほど省メモリで実行できています。
本家版の String Tokenizer は内部で何をしているのかわからないけれど、ループ内で分割 ( split ) 処理を連続して行うとメモリがモリモリ消費されていく。しかも処理が終わってから不要メモリ領域は開放されないため下手にループ処理したら 100 MB とか 200 MB とか平気で消費してる。
処理速度が劇的に向上した件
prester 版では 二次元配列は一次元配列で処理。これだけでここまで処理速度＝二倍以上速い結果が出ることは想定外、だからたぶんエクステンションがユニコード対応しているかいないかで処理速度が変わるのだと思う。
本家版の String Tokenizer はユニコードに完全対応できていないため内部的に文字列を正確に扱えていません。
だから例えば aaa,bbb,ccc;DDD,EEE,FFF; こんな文字列だったら、文字は化けないけど処理速度にはかなり影響している。膨大な数を処理する際にはこれが相当足を引っ張るためここまで処理速度に差がつくのだろうと考えてる。
ついでに試したところ、String Parser2 も多分ユニコードへ完全対応できていない、故に処理速度は遅いです。大量の文字列から配列化しようとする場合、本家版の String Parser2 も String Tokenizer も基本的に無駄に重い処理を行っていることになります。
なおエクステの公開はもう少しかかる予定。