Ver.4.4を目前にして足踏みしている理由について、だいぶんと頭が整理されてきたので、一度ドキュメントを書きます。
INTER-Mediatorでは、コンテキストに対する検索条件を、プログラムから指定する仕組みを持っています。ユーザが入力した条件で再検索するといった仕組みを作りやすくするためものもです。INTERMediatorオブジェクトのadditonalConditionプロパティです。この種のプロパティはいくつかありますが、「additonalConditionプロパティ」で代表して議論します。
今まで、このプロパティは、ページを再合成すると消えてなくなりました。しかしながら、あるページで検索して、別のページに行き、さらに後ほど前のページに戻ったら、同じ検索条件で検索されていて欲しいと思うのではないでしょうか。そこから紆余曲折を端折ると、データベース関連したコンテキストとは別に、クライアント内部だけで利用可能なキーバリューストアの「ローカルコンテキスト」に、additonalConditionプロパティの値も入れて、ローカルコンテキスト自体をキャッシュする仕組みを作りました。キャッシュインやクリア等、APIも用意されています。要約すると、次のような実装になっているはずです（ま、そこもデバッグポイント）。
- 定義ファイルの最初の読み出し（SCRIPTタグで読み込む部分）時において、additonalConditionプロパティがnullであれば、{} で初期化する。ただし、ここでは、キャッシュへの書き込みは行わない実装になっている。
- INTERMediator.construct(); でページ合成を行うときには、キャッシュの値を取り出して、additonalConditionプロパティにセットする。
- additonalConditionプロパティに値を設定すれば、その都度キャッシュをするのが通常動作である。ただし、IE8のみ、1行呼び出しが必要になる。
条件を入力し、検索ボタンを押したときに、上記3のプログラムが動いて、additonalConditionプロパティは設定され、キャッシュもされます。もちろん、検索時に条件として、追加されます。そして、ブラウザを閉じて同じURLを開くと、キャッシュがあるので上記2のメカニズムにより、以前の検索条件が復活して、条件が適用されたクエリー結果が得られます。
そこで、また、別の条件で検索したとします。ここからが問題です。このときに、以前の条件をクリアして、additonalConditionプロパティを {} から構築しなおせば、おそらく問題はないと思います。つまり、キャッシュの内容と、additonalConditionプロパティへの設定プログラムが、同じ意図を持って存在している場合です。検索条件で使うフィールドがいつも同じだと、この条件が成り立つでしょう。
しかしながら、フィールドAで検索するというキャッシュと、フィールドBで検索するというプログラムの両方があったらどうでしょうか？ Aか、Bか、はたまたAとBの合成か？ 合成といってもどうするか？ ここに明確な答えはないと思われます。アプリケーション次第なのではないでしょうか。そうなると、フレームワークとしてはどういう「仕様」を「サポートする」のかというのが非常に決めづらくなります。
additonalConditionプロパティへの設定は、必ずクリアしてから行ってください…というのもありなんですが、残っていることを利用して効率的に設定を適用したい場合もあります。前者は原則で、後者は理解した方はどうぞということになるのでしょうか？ あるいは、キャッシュするかしないかというようなフラグを別途作る事で解決するのか、あるいはより混乱するのか。
この辺りを決めかねています。