特に流れは汲まず、2の方で（書いてもおそらく本家からは何もリアクション無いんだろうなと思いつつ）：
・連想配列
入ってほしいですね、本当に…。。。
しかし、一見HSPとの相性よさそうだと思いつつも、関数が変数に代入できないことを鑑みると他のLLに比べて若干恩恵が微妙なのかなという気がしつつ…。
（ここからは生憎と推測になってしまうんですが）
ただ、OpenHSPでHSP自体のコードを追うと、連想配列対応というのはどうも連想配列用の拡張として添字に数値以外が扱えるような修正を指しているようなんですよね。
で、現状連想配列の土台は作ったものの連想配列自体の実装は全くされていない、と。
上記から察するに、どう連想配列型を文法的に適合させるのか決まってないのかもしれないな、という気がしてます。
例えば、連想配列として思い浮かべる代表的なコードは次のようなものだと思いますが。
m("key") = value// 連想配列：keyにvalueを代入
mes m("key")
しかし、単純に添字に数値以外が使える拡張なら、HSPの型は標準で4次元までサポートするので二次元以上の連想配列はどういう扱いになるのか、とか。
m("key1","key2") = value// 連想配列：「key1」の「key2」にvalueを代入？？
または、実際に連想配列が使えるならこれだけの用法にとどまるハズもなく、例えば連想配列の要素として連想配列を入れたい（ジャグ配列のようなもの）時とかどういう書き方になるのか。
m("key1")("key2") = value// 連想配列：「key1の連想配列のkey2」にvalueを代入？？？
この辺どれが最も現在のHSPの文法に適合した形になるのか不明。
ついでに言うならキーの削除や空っぽの連想配列作る時にどうすればいいのから辺も不明。（やっぱり新しい命令追加で対応？）
今ままで可変長配列や要素型がキーによって可変な配列などがなかったシワ寄せもあるのではないかなと勝手に思ってます。（可変長配列の方はモジュール変数の配列があるみたいですが。。。）
そして、連想配列自体のコピーなどはシャローコピー＆ディープコピーの話も付き纏いますし…。
上記ら辺もある程度揉んでHSPユーザ的にこうあって欲しい、みたいなのがもし開発者に示せたりしたらちょっとはリアクション違うのかもしれないですね、適当に書いてますけど。
・関数と命令
現状#deffuncと#defcfuncは動作的に違いはありつつも、例えば現状の関数でも戻り値使わない場合でさえ「v = f()」な書き方をしないのは格好悪いなという時がたまにあります。
また、関数と命令でそれぞれ同名のものが作れるのかというと作れず、その制限は一体誰が得するの、という気がしてます。
いっそ定義側で関数と命令を分けるのではなく、呼び出し側の書き方で動作が変わるといいとは思うんですが…。
例えば関数形式で呼んだら戻り値はそのまま評価され、命令形式で呼んだら戻り値の型に応じてシステム変数に入る、とかなら下位互換もある程度担保できそうなもんですが。
・関数を値として扱う機能
現在はサブルーチンのラベルを変数の値として扱うことができますが、そうではなく直接関数を値として扱えたらどれだけ便利かと思ったことが何回か。
ついでにいうとクロージャみたいなのも作れたら幸せですが、そこまでは言わずともこれは実装して欲しいですね、連想配列と一緒に。
（可能であればゲーム用スクリプト言語ですしコルーチンも欲しいですね、既にyieldと次の実行コードをラベルで返す機能はあるっぽいですが…。。。）
ただ、呼び出しが関数呼び出しなのか、変数の添字アクセスなのか不明になってしまうという問題がありますが…。
そういう意味で添字アクセスはブラケット（[]）にして欲しいですね。
個人的に欲しいのは上記３つです。
モジュール型をクラスライクに使いたいのかは…私には分からない問題ですね…。
1.userdef.asに書いておくといいこと 2.hspに欲しい機能
