luatexja-otf.sty の挙動
あまり急ぎでもないのでメモ書き程度にしていたのですが，チケット化していただいてお手数おかけしました．
1つ目について: ちなみに，\UTF についてはどうするのが望ましいのでしょうか？ （互換性の目的以外に不要とも思いますが，念のため．）
2つ目について，もう少し詳しくコメントしておきます． luatexja-rmlgbm-data.lua を見ると，unicodes テーブルに以下のエントリがあります．
... ["Japan1.3056"]=36795, -- 一点の「辻」は U+8FBB にある． ... ["Japan1.8267"]=983736, -- 二点の「辻」は U+F02B8 にある． ...ここで，「辻」は字形によらず同一の Unicode のはずなのでおかしいと思われるかもしれませんが，luaotfload では フォント内の Unicode が割り当てられていない異体字については，Supplementary Private Use Area-A (U+F0000-U+FFFFF) に割り当て直すことで あたかも Unicode 内の文字であるかのように扱うようです． そのうえで，GSUB 関連のテーブルにしたがって置換処理を行います． luatexja-rmlgbm-data.lua を検索すると，以下のような行が見つかるはずです．
Fork...
[36795]=983736,
...
[983736]=36795,
...
そして例の場合は，\CID{3056} が展開後には \char36795\relax になるのですが，当然のことながらこれに対応するノードは luaotfload の置換処理によって char=983736 の glyph ノードに変わってしまいます．
解決策としては，attribute で本来の符号位置を覚えておいて luaotfload の処理直後に置換し直すか，feature が全く指定されていないフォントを与え直すか． 後者が楽そうですが，どうでしょうか．
ああ，もし
\char に渡すのではなく，「和文文字」としての適切な値を持った glyph_node をリストに追加する
タイミングが luaotfload の処理の直後にできるのならば，それで2つ目も解決ですね．
\char に渡すのではなく，「和文文字」としての適切な値を持った glyph_node をリストに追加する
タイミングが luaotfload の処理の直後にできるのならば，それで2つ目も解決ですね．
なるほど．水平リストにはとりあえず whatsit ノードとして追加しておいて（こうすれば luaotfload の影響は受けない）， 和文処理グルーの挿入処理時にその whatsit ノードを glyph に「展開」すれば良さそうですね．
気になるのは，\CID, \UTF で欧文文字範囲の値を指定した時の挙動です．もちろん実フォントは和文のものですが，
のどちらにしましょうか？
おお，実装早いなぁ: commit e8c88f1．
気になるのは，\CID, \UTF で欧文文字範囲の値を指定した時の挙動です．もちろん実フォントは和文のものですが，
* そのまま和文文字扱いでノードを追加する→文字幅とかも和文のものに
* 「欧文文字扱い」，つまり JFM の影響はうけない
のどちらにしましょうか？
私としては前者でいいかと思うのですが，どうなのでしょう？ 元の OTF パッケージではどうなっているのでしょうか．
元の OTF パッケージではどうなっているのでしょうか．
実際に試してみたのですが，和文文字幅になるみたいです．
ajmacros を入れてみました (commit 026e2a6)．うまく動くようにいくらか手を入れたので，バグが入っている可能性が高いです． 最後の方にある \ajQuote がなんだかうまく定義できなかったのでコメントアウトしています．
元の OTF パッケージではどうなっているのでしょうか．
実際に試してみたのですが，和文文字幅になるみたいです．
pdvitype で見たところ，JFM が使われているようですね． たぶん「欧文文字出力のために \CID を使う」ことは想定されていなかったんでしょう．
ajmacros を入れてみました (commit 026e2a6)．
ありがとうございます．
ところで，test10-otf.tex にある次の行ですが：
\ajHankaku{半角カタカナひらがな} ←JFM の問題か，半角ひらがなが全角幅で出てしまう．
半角ひらがなの場所が luaotfload によってどこにマッピングされるかフォントによって異なるでしょうから， 単純に JFM を編集するだけではうまくいかないように思います． 解決のアイデアはなくはないですが，最近コードを書こうという意欲が湧きませんorz．
\ajHankaku{半角カタカナひらがな} ←JFM の問題か，半角ひらがなが全角幅で出てしまう．
半角ひらがなの場所が luaotfload によってどこにマッピングされるかフォントによって異なるでしょうから， 単純に JFM を編集するだけではうまくいかないように思います．
和文フォント定義時・文字クラス取得処理に callback の仕組みを加えてみました（kitagawa_jfm_opt branch）．それのサンプルとして， otf.lua で「JFM の文字クラスに属する文字を指定する際に，"AJ1-xxx" 形式も許す」という機能拡張を実装してみました． とりあえず（jfm-ujis.lua に書き加えた）半角ひらがなについては文字幅が半角にできたようです．
# 昨日あたりから小手先の高速化をやっていました．動いているような気配はしますが，
# jfmglue.lua をかなりごちゃごちゃに書いてしまったので，バグ混入の心配はなくなりません．
ちなみに，hwid feature についてはどうしましょうか？ 同様に callback で対応できそうかな．
\documentclass{article}
\usepackage{luatexja-fontspec}
\usepackage{luatexja-otf}
\setmainjfont[NoEmbed,CharacterWidth=Half]{Ryumin-Light}
\begin{document}
あいう
\CID{843}\CID{845}\CID{847}
\ajHankaku{あいう}
\end{document}
ちなみに，hwid feature についてはどうしましょうか？ 同様に callback で対応できそうかな．
少なくとも，先ほど作った callback ではダメです． なせなら，LuaTeX-ja の処理は，順番に
となっていますから．
素直な対応策としては，文字クラスの決定を luaotfload による処理の後に行うように仕様変更することで，
実装もそんなに大変ではないと思います．
（最初にコードを書いた時に，なんでそういう仕様にしなかったんだろう．
たぶん「CID を特別扱いしたくはない」という個人的な心情があったのかなあ．）
文字クラスの決定を luaotfload による処理の後に行うように仕様変更する
これはすでに master ブランチに取り込みましたから，完了とします．
commit 713e444 (in kmaeda-otf) 中の test10-otf.tex に書かれている問題点を，チケットの形にまとめておきます． 以下， test10-otf.tex の該当部分を貼り付けておきます：
現在の実装だと，対応する Unicode の符号位置を取得して単純に \verb|\char| に 渡しているだけなので，以下の問題がある． \begin{itemize} \item 欧文文字範囲に設定されている文字は CID で出力しても欧文フォントになる． 例: あ\CID{18}1あ \item OpenType の feature が指定されているとそちらが優先される． 例: {\jfontspec[NoEmbed,CJKShape=JIS1978]{Ryumin-Light}\CID{3056}\CID{8267}} （左は一点，右は二点になってほしい．） \end{itemize}個人的には，最初の問題への対応「\CID の出力をいつも和文文字扱いにする」のは可能と思います： \char に渡すのではなく，「和文文字」としての適切な値を持った glyph_node をリストに追加する，という方針が使えそう．
# 今日はつかれているので明日にでも書きます．
2つめの問題については，まだ luaotfload のコードを見てないので，今の私にはよくわからないです．