「バグの出方」とは何のことをおっしゃっているのか、わからないのですが、検索だけでなくすべての機能においてバグは起こってはいけません。
「バグの出方」が何を言っているのか理解できないということは、ソフトウェア開発者に要求されるテストスキルが低くて実践的な実力はほとんどありません。と自白されているのと何ら変わりませんよ。
つまり、バグ（＝不具合）がどの機能にどういうバグ内容で出現しているか、それらを全体として俯瞰したときに、バグそのものが減少傾向にあるのか？または、依然としてバグが出続けているのか？を分析することを指しています。分析とは、バグそのものの重症度、機能別の出現箇所、出現深度（※１）などがどうなっているかを網羅的に把握することです。その分析結果に基づいて、ソフトウェアの品質が高いのか、低いのかを判断して、低いところは改善するための打ち手をいくつか考えて実施する。さらに、高いところは本当に高いのかをさらに疑って、さらにテストパターンを増やして厳しいテストを実施して、本当に品質が高いことを確認する。
※１ 出現深度とは、バグの潜んでいる深さを指します。具体的なものはユーザ視点と開発者視点で定義はそれぞれありますが、一般的には、ユーザ視点だとすると、浅い箇所は通常操作でバグが出現する場合、深い箇所は複数の設定などの条件を満たさないと出現しない場合を意味します。私の経験してきたテストでは、言い方は人それぞれありますが、こういことも散々して来ました。
例えば、ソフト開発プロジェクトですと、バグ曲線というグラフを作って、テストケース数の消化率に応じて、バグがどのくらい出ているのかを分析します。そのグラフと検出したバグの内容を考慮して、バグ検出が収束傾向（減少傾向の意）あるかどうか判断して、さらなる打ち手を検討することになります。
EmEditor v23.1 previewのリリース情報を見ると、すべての「クラッシュ」バグをカウントすると１２件あり、その中には上記でいう浅い箇所でユーザに直接大きな影響を与えるクラッシュバグの記載も含まれています。そして、これらのクラッシュバグは、どのバージョンで入り込んだのか情報がないため、このv23.1 previewより前のバージョンから存在していたと判断するのが普通です。
それらを踏まえて、現在のテスト内容は、バグをたたき出すためのテストケースを作成できているか、「～をしているはずだからこれはテストする必要がない」と考えて当たり前にできることもテストケースに設定していないのではないか、ということを非常に心配していますよという意味で書きました。
特に、正規表現を使用した検索機能についていえば、私が報告してきたクラッシュバグについて、本来は江村様がテストで事前に発見して、他に類似はないかも含めて根本修正までするのが普通だと思いますが、それができていませんでした。したがって、バグをたたき出すための思い込みを一切排除した厳しいテストケース、テストデータによるテストケースを作成する考えがあるように見えません。
ご理解しているか怪しいのであえて言いますが、はっきり言って端的に言えば、ソフトウェア開発する人間にバグがあります。例えば、コーディング中に何か別のことをするために手を動かして、自覚なしにキーボードのキーに触れて、知らない間に文字が入力されて、運悪く文字列定義の中だったとします。もし、自分はそんなミスはありえない／しないと考えているとまず気が付くことはないでしょう。そのたった数文字が命取りで、後々バグの原因探しで１週間奔走するということにもつながります。
したがって、私も私自身の作業を信じていません。例えば、ソースファイル内で複数個所で使われている変数名を置換で変更する際は、必ず変更前ファイルと変更後ファイルのdiffをとって、すべての変更箇所が、自分が意図した通りかどうかを確認しています。ただし、前述したことを実現する機能を持っていて使う場合でも、初期はdiffでチェックして性能確認といろいろなケースの実績を蓄積し、もう大丈夫だろう判断になれば、その機能を信用してdiffチェック作業を省略して作業の軽減をします。
理由：バグの出方から気になって気になって仕方がないのと、この機能についてバグなしで安定して動作しないと致命的なため。
私が書いた上記の一文は、本来は開発者としてどういう意味を含んでいるのかを理解していただきたかった内容です。付け加えるなら、以前たくさん書くと理解できないと言われたので、あれこれ言わずにシンプルに書きました。
EmEditorの安定性は非常に重要であり、機能の追加よりも安定性の向上が遥かに重要だと考えています。私たちはAzure DevOps上の「Git」リポジトリから3つのパイプラインを用意し、自動テストを実行しています。毎日数回ソースコードを変更し、コミットすると自動的にテストが実行されるようになっています。巨大なファイルを使用した大規模なテストは毎晩数時間かけて自動実行しています。
テストは何のためにするのかは正しくご理解されていないように見えます。
テスト自体がコミットごとに自動実行するか、手動実行するかは、テスト忘れ防止やテスト工数を削減するための手段であって、これだけではバグ検出して品質を向上することはできません。
バグが見つかるたびに既存のテストケースではなぜ見つけられなかったのか？、そもそもなぜそのバグが入り込んだのか？を考えて、少なくともそれらをカバーする網羅的なテストケースを追加しなければなりません。
また、最近のバージョンではクラッシュレポートを受け付ける機能も追加しました。これは非常に効果的であり、ユーザー様からクラッシュレポートが送信されると私の元にすぐに通知が届き、その日のうちに問題を見つけ修正することができます。もちろん、バグは避けるべきですが、テスト漏れやバグがリリースに残ることもあるかもしれません。完璧なソフトウェアは存在しません。
「クラッシュレポートを受け付ける機能」については、どのバージョンから搭載されたかわかりませんが、少なくとも去年の正規表現関連不具合でクラッシュしたことが、原因特定で試したのを含めいて２０回以上ありましたが、一度もクラッシュレポート機能が動作するところを見たことはありません。すべていきなり強制終了でした。
文章上の表現だけだと思うのですが、念のため言っておきますと、「バグは避けるべき」ではなく、「バグはなくすべき」と考えなければなりません。つまり、常にバグが発生しないためにはどのようにコードを書くべきか？（if文に記載する条件一つについても）、クラス構成やデータ構造はこのままでよいか？を徹底的に考えて、考えたコード単位の動作検証して、実装に反映させていく必要があります。
「バグは避けるべき」と甘く考えるソフトウェア開発者には、バグの少ない高品質なソフトウェアは作れません。
しかし、バグが見つかっても迅速に対応することでユーザー様の信頼を得ていると思います。もしかすると、頻繁な更新と多くのバグ修正があるため、そのように感じられているかもしれませんが、バグを放置するよりも更新を提供する方がユーザー様のためになるのではないでしょうか。
ユーザの信頼を得ることについて、考え違いをしているので、ここでもあえて言わせていただきます。
見つかったバグで、ユーザはどのような被害を被ったかまたは被るかを考えたことはありますか？
上の方で書きましたが、例えば、クラッシュを引き起こすバグは、ユーザが作業中の未保存のテキストデータをすべて損失させます。回復手段はありません。あるとすれば、定期的にスナップショットを保存するくらいでしょう。
さらには、そのユーザがそのテキストデータを作成した時間（工数）も失い、もういちど同じアウトプットを作成するために最低でも同一の時間（工数）を必要とします。
そのバグが原因でユーザ本人に仕事を依頼した依頼主に渡すはずのアウトプットが、予期せずに損失して真っ青な顔で期限ぎりぎりまでに再作成せざるをえない状況に追い込んでいたらどうでしょうか？
ユーザ本人が、EmEditorが原因だとわかっていても、依頼主にそんなことは言えませんよ。言ったらどうなると思いますか？簡単です、評価が下がります。つまり、依頼主からすれば、この人は自分の仕事の遅れをバグることなんてないテキストエディタを言い訳にする人なのかと認識されて、その組織で重要度の高い仕事の場合は、外されてしまうリスクがあります。１度ならまだしも、何度もあれば重要な仕事は任せてもらえなくなります。
したがって、そのような経験をしたユーザであれば、安定してテキスト編集ができるEmEditorの信用がすべてなくなり、怖くて使えないのでほかのテキストエディタに切り替えて仕事を続けることをするのが普通の判断と対応になります。
そのユーザにバグは修正しましたこれで安心して使ってくださいという意味で、手早く更新を提供しても、ユーザが使ってみたら類似の使い方でクラッシュして再度テキストデータを損失する経験をしたらどう考えると思いますか？
難しくはないですよ。このソフトウェアと開発元は信用してはいけないになります。
例えば、ソフトウェアではないですが、ソフトウェアのクラッシュバグ相当の事例として、ボーイング社の旅客機のドアが航行中吹き飛んだ事件がありました。
BBC News Japan – 【解説】 米ボーイングにとって深刻な問題 主力機のドアが航行中に飛んだ事故
離陸後の上昇中に発生した事故で、全員が運よくシートベルトをしていたので、誰一人外へ投げ出されずに済みました。
もし、江村様がこの旅客機の吹き飛んだドアの座席にシートベルトをして着席して、この事故を経験して無事に生還できたとします。
そのあとに、仕事でどうしても旅客機で移動する必要があるとしたときに、もう一度同型の旅客機乗りたいと思いますか？あるいは、同一メーカのすべての旅客機に乗りたいと思いますか？
私なら、金額が少々高くついても、命には代えられないので、可能な限りボーイング社の旅客機は避けて、かついずれのドアからも距離をとった座先を予約します。
この例えの続きでいえば、ボーイング社が迅速に問題を修正しましたので、安心して同型機にご搭乗くださいと修正版同型機をリリースしたとして、客は信用しますでしょうか？しかも、調べてみるとほかにもボーイング社の旅客機で不具合が起きていることがわかった。
このような状況では、事故経験の有無に関係なく客はドアどころか通常の窓も吹き飛ぶのではないかと疑心暗鬼になります。この事故に遭遇したらなくなるのは自分の命になるため。
飛行機事故の事例を出したのは、ソフトウェアのバグも状況によってどれくらいの影響をユーザに与えるのかを理解いただくためです。
ユーザが何をもって信用するかは、「対応の迅速さ」ではありません、「バグを完全解消した実績」です。対応の迅速さを売りにする人は山ほどいますが、仕事はいい加減な人ばかりです。
したがって、実績以外に信用に足るものはありません。もちろん、短い時間でいい仕事（言ってもいないことで、頼んだ側の事情を汲み取って次の仕事に手間なく取り掛かれるようにアウトプットをフォーマット込みで考えて出してくれる）する人もいますが、全体としては少ないです。
[高度] ダイアログの [正規表現「.」が改行コードに一致することができる] オプションがこれ相当します。
regexオプションのsに相当しますと説明したいのだと思いますが、それだけでは機能しません。それ以外に、[高度]ダイアログの[正規表現で検索する追加行数]を検索対象の文書の合計行数以上に設定しなければなりません。
二つの設定項目を適切に設定して、初めてregexオプションのsを設定したのと同様に正規表現検索できるようになります。
正規表現そのものの理解と、実装されている上記のオプションの関係が理解できているかが心配になったので書きます。
２．と３．は、２つでワンセットです。最初は、２．だけでしたが、これだけだとこちらの意図が伝わわず変な実装をされる不安があったため、３．を書き足しました。
この不安は、残念ながら的中してしまいました。
3.～10. については検討します。
したがって、２．～１０．までを検討範囲としてください。
当然なのですが、この中には文章として表現されていない「隠された要求仕様」が含まれています。くれぐれも慎重に深く洞察いただいて、考えていただきますようお願いします。
というものの、まさかの実装を検討するということでしたので、少し書きます（追加の要求仕様の実装自体は却下されたと認識したので、実現はあきらめていました。それならそれでなぜの理由を聞いて、このやり取りは終わりにするつもりでいました）。
UIに実装する際の文言表現（ユーザがこの文言表現でどういう機能か？どういう効果があるか？を正しく理解できるか？）、UI上の機能配置の仕方（オプションは、[高度]ダイアログに配置したほうがいいか、[検索]ウィンドウに配置したほうがいいか）についても「隠された要求仕様」に含まれています。さらには、強く関係する他の機能もどうするかも含んでいます。
EmEditorのメニューで選べる機能名は、何のために使うのか、どういう効果があるのかが、わからない名称のものが散見されます。もし過去にその機能を要求した人がいたとしたらその本人にはわかるでしょうが、私にはよくわかりません。したがって、こういう作業にはよい機能があっても、実質その機能が使えない状態になっているため。
はっきりと言えば、検索・置換機能についていえば、動作挙動、主要な名称については、世の中で多く使われて通用しているものに合わせていただきたい（最低でも、それらを踏まえたものにしてほしい）。ここから外れるのであれば、ヘルプでこれを設定するとBoost.regexのどのオプションを設定したことになるのかなどを説明を記載してほしい。特に、江村様が実装された検索挙動については、明確にわかるようにヘルプに記載するべきです。
長く書いてしまいましたが、いずれにしても実装却下されたと認識していた追加仕様について、実装を検討されるとの回答でしたので、期待はせずに運が良ければ希望がかなうかもしれない程度に考えておきます。