さて、先にまとめられた２つのタイプでも、やっぱり次のような問題があるんではないかと思った。
「ボタン/メニュー」型では、常にある階層などに整理する必要があり、また使用時にはその静的な階層を追って検索していく必要があること。そのために、やっぱり対象が多くなるとどうしても繁雑になり勝ちだということ。
もちろん、対象アイテム数が少ない場合には、とあるアクション（ホットキーやマウスが近付く）で必要な時だけ現れるランチャーなどは特にその威力を発揮する。
また例え数が増えたとしても、目に見えて選択できるという意義は大きい。だからこそ標準のスタートメニューはアプリケーションのインストールで自動的に保守されることとも相挨って、例えその繁雑さがあっても標準的な道案内として効果がある（そして、それを模倣/継承して使いやすく置き換えるアプリケーションという存在もある）。インターネットでも Yahoo! のような検索サイトが「ディレクトリ型」と呼ばれる所以でもあると思う。
一方でいえば、コマンド型の方はといえば、それ自体としては完成度が高いんだけど、いかんせん UNIX 出自というのが祟って、Windows の exe 管理（PATH 変数に設定されない場所にある）や、普段目にするスタートメニューと exe 名との違い、そもそも exe 名が連想しにくい（exe 名はほとんどが8文字に圧縮されている）ことから、ちょっとギャップがあるものが多かったりする。
そして、件の検索ということでいえば、あくまでまだコマンドラインの由来でもある「ライン＝１行」という制約の中にあって、特に検索結果の表示においてユーザの入力と出力結果がわかれていることが不満で、GUI に慣れて来て軟弱化（これを軟弱化と言ってまうのもある種の偏向だけど）した身としては、あと数個ならば文字を打ち込むまでもなく「選択」したいという思いが出てくる。
こういった判断には、キーボードやマウスの操作への好き嫌い、他の環境との兼ね合いなども個人的な要素も影響してくる。
けれども、私自身の思いとしては、
という方向への展開がアプリケーションの系譜としてあってもいいんじゃないか、と。
これは全文検索型のランチャーともいえて、それは各種の辞書アプリケーションやさらには Infoseek や Namazu 等の全文検索型のようなインターフェースをランチャーの世界に持ってくるということだった（中身を全文検索する Infoseek や Namazu と違って、あくまでファイル名の集合をテキストと見做しての検索だけど）。
つまり、対象ユーザの状況としては、まず起動したいものの一部分の言葉でも思いつくことを前提としている（ここに関してはユーザ側に依存する）。それに従って、アプリケーションの側は動的にリストを絞りこんで、ユーザ側が簡易に判断できるレベルまで複雑さを緩和する。そんな関係を導入したかった。
具体的には、ユーザの主たる入力としては「綴り」にした。そして、１字１字打っていくという動作が潜在的に持っていた、集合の中から「選択」するという行ないを、リストの形で動的に視覚/実体化することで、ユーザの想起をサポートするということだった。そういう意味で、綴り型を継承する位置付けとしていた。
また、入力とリストを分け、リストを選択操作可能としたおかげで、部分文字列での検索との親和性が良くなった。今までのコマンドラインでは、最終的に文字で打ち込んで行って決定する必要があったために「前方一致」という制限があったのが、そこに縛られる必要がなくなったからだ（まぁ、UNIX でいえば、locate というより強力なやつがいるけど。さらには、find や grep やらを組み合わせれば、そもそも強力な検索機能となっている）。
※実際の動作イメージは リンク先の図を参照
だから、ボタン/メニュー型を支援するために「文字/綴り」型のやり方を導入するパターンではなくて、コマンド型を支援するために「アイテム/オブジェクト」型のやり方を導入するという方向性を取った、というようにもまとめられると思う。
こんな風に考えて、これは面白い試み、と自分でも位置付けられたものだから、怠け者もその活動の夜を迎えて動き始めたんだ（と、一人納得）。 でも、そういったのがすぐ見つかっていたら、やっぱり作らなかったろうけど（でも、後で見つけた…。 検索ランチャー栞との比較 を参照）。