フォーラムの返信を作成しました。
- 投稿
理由が分かりました。
結論から言えば，case insensitive（大文字・小文字を区別しない）における Onigmo の動作の仕様といっていいと思います。
Ruby などで実験しても同じです。
case insensitive のとき，U+017F LATIN SMALL LETTER LONG S という文字が「s」や「S」にマッチします。
この文字はラテン文字の小文字の普通のエス「s」のいわば異体字で，日本語でも「ロングエス」と言います。音価なども同じ。対応する大文字は普通の「S」です。
写本や初期の活版印刷で使われていました。試しに検索ダイアログに \x{014F} を入れて，大文字・小文字を区別しない，で検索してみてください。「s」や「S」にマッチしますね。
[\x{0080}-\x{FFFF}] の範囲にこのロングエスが含まれているために，「s」「S」にマッチしたんですね。
一方，U+212A KELVIN SIGN という記号があります。これは温度のケルビン記号なのですが，既存コードとの互換性のために用意された文字であり，ふつうはケルビンの記号にはこれでなく普通のラテン文字の「K」を使うことが推奨されています。
これも，case insensitive の場合はふつうの「k」「K」にマッチするんですね。
興味深いですね。
「大文字と小文字を区別する」が ON だとこの現象は起こらないようです。なお，非 ASCII 文字の検出は \P{ASCII} でできます。
[\x{0080}-\x{ffff}] だと基本多言語面（BMP）外の文字にマッチしません。Source Han Code JP は実質固定幅フォントですが，フォントデータとしてはプロポーショナルになっているのですね，なるほど。
Source Code Pro は全角括弧類が半角に表示されるのでソースコード表示に向いてないんですよねー（半角の括弧類との区別が確認しづらい）。
釈然としませんが，諦めます。
Atom だと Source Han Code JP でも正しいインデントガイドが表示されるんですけどねー。なるほど，そういうことですか。
文字幅の平均値などというものに意味があるのかどうか疑問ですし，平均値が x の幅になるというのが普遍的とはとても思えませんが，それはそれとして。ルーラーの目盛りが何を表すかは置いておいて，インデントガイドはルーラーと切り離して考える，というわけにいかないのでしょうか。
ルーラーは，和文全角・欧文半角のような特殊なフォントを除けば〈目安〉にしかなりませんが，インデントについては，スペース 2 個のインデントの位置はスペースの幅 2 個分右に移動した位置であって，何ら曖昧性がありません。
よって，インデントガイドは当該フォントのスペースの幅を基準に引いてくれればどんなフォントを持ってきても誰もが happy だと思うのですが。> ソース コードの表示に使用される場合には、固定幅のフォントを使われることをおすすめします。
Source Han Code JP は固定幅フォントです。
分かりました。ということは，Windows のバージョンによって微妙に仕様が異なることもありうるのですね。
さて，最初の要望に戻りますが，String.prototype.replace() でできなくていいので，EmEditor の正規表現エンジンが使える API（という言い方でいいのか？）のようなものをご検討いただけると嬉しいです。
var e = new RegexEngine("Onigmo"); modifiedText = e.replace(sourceText, /regex/, replaceText);みたいなイメージです。追試しました。
後方参照を使うかどうかは本質ではなく，要は検索でキャプチャーした文字列が，Onigmo だと置換側で \1 で参照できない，という問題のようです。
以下で再現します。テキストは「あいう」でも何でも OK。タイプ：カスタム
一致した文字列を隠す／正規表現で置換する：ON
正規表現：ON
検索：(.).*
置換：\1Boost だと各行の最初の一文字がアウトラインバーに表示されますが，Onigmo だと表示されません。
ICU 対応すれば，
Character classes that are supported by Unicode Regular Expressions
http://www.boost.org/doc/libs/1_57_0/libs/regex/doc/html/boost_regex/syntax/character_classes/optional_char_class_names.html
が使えるようになるだけでなく，Han やKatakana とかも使えるようになるってことでしょうか？
とにかく漢字，両仮名などの文字クラスはどうしても欲しいです。
このあたりが貧弱なために，いちいち Ruby スクリプト書いたりしてます。速度面はどうでしょうか。
最近の信頼できそうなベンチマークが見つけられませんでしたが，古いウェブページで Boost.Regex より鬼車（当時は鬼雲は無かった）のほうがかなり速いという情報もありました。
それから何年も経ってるので今は分りませんが。
もし鬼雲のほうが確かに速いとなれば，巨大テキストの処理速度を重視する EmEditor にとって有利に働きますね。鬼雲の技術面については，『正規表現技術入門―最新エンジン実装と理論的背景』（技術評論社，2015.4）が役に立つかもしれません。著者の一人が鬼雲の作者です。（本全体は鬼雲について書かれたものではありません）
http://gihyo.jp/book/2015/978-4-7741-7270-5「大文字と小文字を区別しないなら [[:lower:]] に意味は無い」のは仰るとおりなのですが，これはたまたま見つけた不具合でして，こんな基本的なところにバグがあるなら（プロパティーの文字クラスは）怖くて使えない，という気持ちがこの報告の背景にありまして。
過去に他のテキストエディターで，正規表現ライブラリーには問題が無くて呼び出し方の問題で検索動作が微妙におかしくなるという現象がありました。
Boost.Regex 側の問題であるかどうかだけでもはっきりするといいのですが。製品がおかしいのではなく，何らかの原因でうちのメニューが壊れちゃったということなのですね。
分かりました。
「リセット」するとメニュー全体が元に戻っちゃうので，選択項目だけをリセットすることができたら便利ですね。それと，メニューバー（？）とコンテキストメニューとで，メニュー項目名が「区切り値／並べ替え」「CSV/並べ替え」と食い違っているのはいいのでしょうか？ 中身は同じようですが…。
プラグインは追加していませんが，念のため全部外してみました。
マクロについてですが，「マクロ」→「カスタマイズ」の「マイマクロ」で，どのマクロを選んでも「イベントで実行」が OFF であれば，イベント割当ては行っていないと考えてよいのでしょうか？ であれば，割り当てていません。
バージョンは報告時 Version 14.6.0 beta 9 でしたが，beta 10 でもやってみました。
結果は同じです。
レジストリはあとでお送りします。14.6.0 のベータ版を触ってみましたが，やはり「CSV のセル単位の置換」機能はぜひとも実現してほしいですね。置換ダイアログに「セル単位」といったチェックボックスでも付けて。
CSV データを整えたいという需要は非常に高いと思うんです。
繰り返しになりますが，セル値の先頭・末尾の余計なスペースを削除するとかですね。Ruby や Python，Perl のようなプログラミングができる人なら，言語に付属の CSV ライブラリーを使っていとも簡単に CSV データの加工ができます。
でもそれができないのでテキストエディターでなんとかしたい，という人は大勢います。
セル値が改行やカンマを含まないなら，正規表現でどうにかなりますが，それらを含むなら極めて難しくなります。
この穴を EmEditor に埋めてほしいんです。もう一つ例を挙げます。
たとえば，セル値がabc，def
だったとします（カンマは全角）。
このカンマを半角カンマ＋半角スペースに置換したいとします。
置換したときに“abc, def”
のようにダブルクオートが付くことを期待しますが，現状では付いてくれません。
RFC 4180 的に正しい CSV を CSV モードで開いているにもかかわらず，置換して保存すると，部分的に列のずれた CSV だったり，RFC 4180 で解釈できないデキソコナイになってしまうのです。
これでは危なっかしくて CSV 編集に使えません。将来のバージョンでもいいので，「編集時に CSV らしく表示する機能＋α」でなく，「CSV データとして編集する機能」をぜひともご検討いただきたく。
「えっ？ そんな機能があるの？」と思ってやってみました。
選択範囲に改行が含まれていればインデントされ，含まれていなければタブに置き換わる，という動作でした。
マニュアルにもう少し詳しく書いてほしかったですね。
それと，ちょっと危ない仕様だな，と思いました。テキスト末尾が改行を含まない場合，その行全体を選択しても，タブキーでインデントになりません。これはやや不便です。
「キーボード」設定で，「編集」の「インデント」「逆インデント」に何かキーを割り当てちゃえば，自分の好きなキーでできるようです。
すべては私がこのダブルクリック操作の意味を勘違いしていたせいなのですね。お手数をおかけしてすみません。
「編集を続行して保存するとファイルの中身が壊れます」の意味も今やっと分かりました。そうやって読み直したあと編集して保存すると壊れるよ，ということだったのですね。ただ，やはり「指定したエンコードで変換できない文字が含まれています。」という文言は日本語として変だと思います。
ここで表現すべき内容は「指定したエンコードでは解釈できないバイト列が含まれています」ではないでしょうか？
（ただ，「バイト列」とかいうと分かりにくい人もいると思うので，これは「文字」としたほうがいいかもしれませんが）「一覧から選択する」の意味は分かりました。うーん，そういうことなら「エンコードを指定して保存する」って書いてほしいですね。
[次の Unicode 文字を検索] についても分かりました。自分が EmEditor の便利な機能を全然把握してないことが分かりました。勉強します。
この機能があればとりあえず私は十分です。
ただ，「一覧から選択する」で出る「名前を付けて保存」ダイアログをキャンセルしたときにも赤になったほうが動作が一貫しているような気がします。ところで，「Unicode 文字を検索」のほかに，「BMP外の文字を検索」が欲しいです。未だに BMP 内でしか Unicode が扱えないソフトウエアが少なくないので。
あと，「JIS X 0208 外の文字を検索」もあると嬉しいです。
