ボーンのサポートについては現在検討を進めています。

10年くらい昔のロードマップではVer2.5で搭載予定で、
その布石としてVer2.4でローカル座標をサポートしたのですが、
その後に内部構造の大幅改良を行う時間をとれる見込みがなくなり
Ver2.5自体をキャンセルせざるを得なくなった経緯があります。

今ようやく内部構造の大幅改良を行える算段が立つようになったので、
まずは検討のみという段階にすぎませんが、
速度面や将来の互換性への懸念があることには変わりがないので、
もし正式にサポートするのであれば中途半端な仕様の採用ではなく、
今後長らくは大丈夫な実装にする必要があると思っています。

ただ、ユニークIDでは難しいという理由はどういったものでしょうか？
現在だとオブジェクトの変更通知に対してその理由を知ることができなく、
頂点の追加・削除を検知するために総当たりが必要になるため面倒だというのは
わかりますが、決して困難ということはないと思います。
もし速度面が問題だとしても、実際にどの程度かは検証していませんが、
いまどきのCPUであれば頂点数が少なければ大したボトルネックでもないような気がします。

実装方法については色々検討したいので、こういった面について
ご意見お聞きせいただけると幸いです。

現在の頂点のユニークIDはオブジェクト内でのみユニークなので
ユニークIDではコピー、ペーストやオブジェクトの合成などでは追いきれないと思います。
オブジェクトが変化するメッセージは、OnUpdateObjectList(オブジェクトの作成、削除)とOnObjectModifiedがあると思うのですが
10万ポリゴンのオーダーのモデルを編集時に頂点を移動しただけの時やオブジェクトの表示/非表示をしただけで
10万オーダーの全検索するのはあまり現実できではないと思います。
ユニークIDを使用するならばせめて何がどのように変化したか(オブジェクト1の頂点1が削除されたとか)のメッセージを送るべきだと思うのですが、どうでしょう?

頂点ごとの詳細な変更内容を通知しようとすると、その情報を保持すること自体が
重くなる要因になりやすいです。
実際にstd::setやstd::mapを使うと、10万程度ならいいのですが、
100万以上となるとかなり重いです。
検証こそしていませんが、下手に情報を保持するよりも総当たりのほうが軽くなる
ケースすら出てくるかもしれません。

また、追加・削除だけならともかく、例えば複製など変更内容の種類が増えると、
今度はプラグイン側の対応が大変になったり、
さらなる仕様拡張で種類を増やすことも容易ではなくなるので、
余程かなり慎重に仕様を検討しないとおそらく将来的に破たんします。

そういった意味では、OnObjectModifiedの仕様を現状より複雑にするくらいなら、
頂点ごとに保持するほうがシンプルで拡張性も持たせやすいとは思います。

そうですねプラグイン側としても頂点ごとに保持してもらったほうが楽でいいですね。

ただ一応このままユニークIDを使うとして、変化したもののメッセージを送るかわりに、変換したもの(頂点や面)にダーティーフラグを立てる方法もあるかと思います。
ただこの方法も毎回ダーティーフラグをクリアしなくてはならないのと、
削除したものは全検索しなくてはならないという欠点があるので、
あまり良い方法ではないかもしれませんが…

回答有難うございます。

ボーン対応予定の話は吉報でした。
多くのユーザさんが喜ばれるのではないでしょうか。
 
ユニークIDの問題ですが概ねはSSSさんの言われるような点です。
ご指摘のようにOnObjectModified前後でジオメトリ情報を記憶しておき
総当りで比較する事で推測する事は出来なくはないですが目的の手段に対して
必要となるコーディングコストが重過ぎます。後は保守性の問題といいますか、
将来的に頂点形式が変わると対応できないというのもあります。
その対応に目的の機能のよりも実装工数がかかるのは日曜プログラマ的には
ちょっと厳しいなぁと。
 
ボーンを実装する上で少なからず頂点のデータサイズを任意サイズで拡張できる
様な設計になると思います。その辺をある程度プラグインイに開放して頂けると
私的には有難いです。
私もどういったものを求めているのかというのはまだ漠然としていますので
一度意見をまとめておきます。差し支えなければ検討段階でも良いので今後の
構想など聞かせて頂けたらと思います。