丁寧なご回答ありがとうございます。
（１）～（３）までのご回答で、EmEditorにおいての検索機能の本質を理解することができました。
正直申し上げますが、#31408の江村様のご回答を初めて読んだとき、説明していることがまったく理解できませんでした。もう一度読み直して、一行ずつ文章の意味を慎重に理解して、最後の行まで理解したときに、頭が野球用の木製のバットで叩かれたような強い衝撃が走りました。別な言い方をすれば、ビルのオープンな１階フロアに入ろうとしたら、綺麗に磨かれたガラスの壁にまったく気づかずに頭をぶつけた時のような衝撃です。
回答いただいた（３）に書かれたEmEditorの検索動作（アルゴリズム）について、通常のエンジニアの認識と、私の動作希望について書かせていただきます。
（３）で江村様の検索の動作の考え方ならびにEmEditorの検索の動作（アルゴリズム）は、世界（グローバル）のどの情報技術に関係するエンジニアの１００％がおかしい挙動をしていると認識します。
私は１０年以上情報技術のエンジニアをしてきました。OSは、Ubuntu, Redhat, CentOS, Windowsなどを扱ってきました。テキストファイル内の文字列検索をする場合は、コマンドを使うか、テキストエディタを使うことになります。例えば、Linux OSであれば、sed, grep, egrepが有名な正規表現に対応したコマンドになります。Windows 10であれば、findstrコマンドになると思います。テキストエディタだと、LinuxOSではシェル上で動作するemacs, nano, vimあたりが有名でよく使われます。Windowsだと、Emeditor以外ですと、Sakura Editor, 秀丸エディタ, Notepad++などフリーを交えて有名どころで使われています。ただし、個人的によく知っている範囲です。
これらのコマンドやテキストエディタを状況に応じて使ってきました。しかし、どのコマンドやどのテキストエディタにおいても、（３）の検索アルゴリズムで動作するものは一つもありません。
「エンジニアの１００％がおかしい挙動をしていると認識します。」と断言できたのは、世界中で使われているLinux OSに搭載されているテキストファイルの文字列検索コマンドが（３）の検索アルゴリズムではなく、私が認識している検索アルゴリズムを採用していて、世界中のエンジニアの間では常識になって言います。したがって、仮にそれらのコマンドのいずれかに（３）のアルゴリズムを検索機能として実装したとすると、確実にユーザからバグとして報告され他のエンジニアによって修正されます。
江村様は、どうも検索の機能の本質を理解されていないようです。検索機能は、検索対象のテキスト文書の中で検索文字列が重複なくどこに何個出現しているかを特定する機能です。江村様の考えた検索機能は、検索機能の必須条件を満たしていません。ちなみに、江村様が個人の範囲で使うのもインターネットを使ってその考え方を発信するのも自由です。
しかし、無料／有料問わずテキストエディタとして、文字列の検索機能を提供する場合は、まずは他のテキストエディタでは、検索機能のアルゴリズムはどうなっているかをよく調べて、自身の検索アルゴリズムの違いはあるか、あるとそればどこになるかを明らかにして、ヘルプやテキストエディタの機能の説明欄などに明確に動作を説明するべきです。
私なりに、わかりやすく順序だてて説明したつもりです。
シンプルに言えば、EmEditorの検索機能のアルゴリズムが世界中で使われているテキストエディタと文字列検索コマンドにおいて検索機能のアルゴリズムが全く異なります。（３）のような考え方のアルゴリズムで検索機能を実現しているのは、EmEditorただ一つのみです。
江村様の次の説明が非常に気になりました。
しかしながら、私の知る限り、ほとんどのテキスト エディターは EmEditor と同様の動作をするはずです。
「～はずです」という言葉を使うときは、私の経験上間違いなく、現実の現物を一切確認しないあるいは中身を確認せずに表面だけ確認して、机上の空論で自分が正しいという場合に使われます。
なぜ、このようなことが言えるのかというと、過去において組織の中で、「～は書類に書いてあるはず」「～はだれだれがやったはず」などいう人が多くいました。役職なしの社員だったので、安心して実際に確認すると、書類には書いていなかった、それどころか書類が作られていなかった、誰もやっていなかったということしかなく、結局自分がそれらの後始末せざるを得ない状況に追い込まれた経験が山ほどあるためです。こういう経験を何回かしてからは、「～はずです」という説明自体を信じないで具体的に確認するようになりました。また、そのような言葉遣いをするいかなる人も信用することはありません。理由は、「～はず」の説明を信じて行動したら、説明されたことができていなく、それを自分の責任にされるという裏切りを何度か経験したため。こういうことをする人に限って、ごまかしたりだましたりする説明が全員なぜか上手でした。
しかしながら、私の質問に対して、正面から正々堂々と一つ一つ丁寧に回答いただき、誠意を感じましたので、余計なことかもしれませんが、世界の「検索」のデファクトスタンダードとなっているアルゴリズムについて説明させていただきました。
世界中で実装されている共通の検索アルゴリズムの考え方を前提に下記についても、気になったので私の考えを書かせていただきます。
その理由ですが、検索の際には、考えられるすべての一致を検索するべきだからではないでしょうか? そうでないと、重要な検索一致箇所を見逃す可能性があります。
しかし、ユーザーは &A& と &C& の間にある &B& も一致されることを期待するはずです。&A&、&B&、&C& の 3箇所の重要性は同じだと考えられます。
そこで、[次を検索] コマンドでは、できるだけ多くの可能性を見逃さずに一致させることを意識しています。
上記の２つの引用で示した江村様の考え方は、「検索」（検索文字列の出現箇所を重複なく特定することが主目的）ではありません。パターンの出現箇所を一部重複を許容して特定することが主目的になりますので、造語になりますが、「パターン検索」、「パターン置換」が機能名として正しいです（機能の目的または効果を直感的に理解できる機能名であることが重要です）。
検索機能では、検索する文字列の一部が重なるような出現を許容しないためです。しかし、上記のような機能も昨今のAIブームでパターン認識のやり方や見つけ方が重要になってきていますので、もしかするとニーズがあるかもしれません。
パターン検索という機能であれば、検索文字列をパターンとして考えて、検索文字列の一部が重なることを許容することが必要になるためです。
AIともてはやされてはいますが、使われている技術としては深層学習（Deep Learning）を基本にして、ニューラルネットワーク構造の工夫と扱えるパラメータ数を飛躍的に向上させて、質問理解（現時点では正確には統計的な理解と思っています）とその最適と推定される回答を学習したデータから生成することができるようになり、昨今あちこちで実装されてサービス提供がされるようになったのがざっくりとした私の認識です。
このAIに関しては、最初は画像が主だったのですが、昨今はテキストを扱えるようになり、パターン認識というのがキーワードとしてあちこちに登場するので、ひょっとしたらと考えた次第です。
私も、この分野には明るくはないのですが、AIに参戦して開発をしているのが、Google、マイクロソフト、メタなどいわゆるビックテック企業とベンチャー系企業で、どうなっているかたまにIT系ニュースで見ていますが、雨後の筍のようにサービスが立ち上がったり、新しいAIが出てきたり、古いタイプのAIがいつの間にかなくなっていたりしながら、企業同士の混戦模様に見えています。
したがって、どなたかのユーザさんがAIの機能やらマクロやらを作ってほしいという要望があるようですが、それらは使いたい本人が詳しいでしょうからご自身でマクロを作るなり、市販のAIツールなどを使うなどの元来エンジニアがするべき工夫してうまく使いこなしていくもらうことで問題ないですし、私の提案した機能についても一旦EmEditorの機能からは取り外して、今は動向をウォッチしながら静観して、必要に応じて再調査と再検討をされるのがよろしいと思います。
しかしながら、yasuji 様のお考えの動作を希望される場合には、オプションの追加も検討いたしますので、再度、その理由も含めてご連絡ください。
それでしたら、私が説明した検索のアルゴリズム（動作）を現時点での検索機能と別で新検索置換機能として搭載していただきたので、具体的な希望とその理由を別トピックを作成してご連絡させていただきます。