MQSelectLineにobject\x2cface\x2clineの項目があるんだから
lineの両端にある頂点を自分でリストアップしていけばいいだけでしょ

で、LineIndex と頂点との関連性はどこに？

それと文語体に対しては、口語体で答えないでください。非常に失礼だ。

人の文体注意する前にまずプログラマとして最低限のことをしたらどうですか?
とりあえずSDKのマニュアルは読みましたか?
一通り読んでいれば構造体見れば普通に一発でわかるものだと思いますよ。
それでもlineの意味がわからなければちょっとしたテストルーチン書くだけですぐ調べられますよね?
何故その程度の労力を割かないのですか?

説明をするとすれば、lineは面の中の頂点のインデックスを示すもので、
lineとline+1が両端の頂点にあたるものです。
以下が実際にvertexsに選択頂点をリストアップするルーチンです。

vector<MQSelectVertex> vertexs;
for(int i=0;i<doc->GetObjectCount();i++){
    MQObject obj=doc->GetObject(i);
    if(!obj)continue;
    for(int j=0;j<obj->GetFaceCount();j++){
        int point_count=obj->GetFacePointCount(j);
        int point[4];
        obj->GetFacePointArray(j\x2cpoint);
        for(int k=0;k<point_count;k++){
            if(doc->IsSelectLine(i\x2cj\x2ck)){

内部的にも面内頂点にそれぞれUV座標を持つのみで、
UVについてSDKレベルでアクセスできる情報以外のものはありません。

そのため、UV頂点の単一化の操作もUV座標を同じにするのみで、
結合されたものかそうでないかという区別はありません。
つまりUVには頂点という明確な概念が存在しません。
選択・移動の際にも同じUV座標のものを探し、一括して操作しているだけです。

Miznoさん自ら回答ありがとうございます。

UV座標が同じであれば、単一頂点とするということで扱うように処理します。

亀レスですが、現行のβ版ではシェーダからバンプマップにアクセスすることはできません。
バンプマップ自体、存在意義や仕様が不明確なままですが、
バンプではなく法線マップとするか、あるいは無意味なので廃止するかなど、
今後どのように取り扱うかも現状でははっきりとは決まっていません。

具体的に、Bampマップをどのように利用しようとしたかったのかというと、
現在HLSLフォルダに用意されている、Phong、Blinnの各シェーダーをカスタマイズしてBampマップに入ってるテクスチャをノーマルマップ（法線マップ）として扱い、ビュー上でノーマルマップを反映させたいと思っていた次第です。
（バンプマップにアクセスできたとして、出来る出来ないはやってみないと分からないという状態でしたが）

これを踏まえて質問をしたいのですが、

・バンプマップにアクセスできたとして、それをノーマルマップのパスとして受け取った場合にノーマルマップとしての描画結果を得ることが可能なのか
（単純にテクスチャパス以外にも、シェーダーをカスタムするだけでは駄目でメタセコの方でノーマルマップとして使用できるようにするなんらかの準備がいるのか？）

・取り合えず次期バージョンで、バンプマップとしてでいいのでシェーダーからアクセスできるようにして頂けないか
（上記の検証をこちらでやってみたいので、単純にアクセスできるようにだけできないでしょうか）

・バンプマップ、ノーマルマップの扱いの要望
ノーマルマップ自体もパララクスマップのような進化系のようなシェーダーが存在しているので、単純にバンプマップからノーマルマップへの移行になってしまうと汎用性が無くなります。
（シェーダーで扱いたいマップが、バンプやノーマルマップ以外にもあるので）

そういったマップは、シェーダーマップとして模様、透明の下に複数追加できるようにして、ShaderMapSampler1\x2c2\x2c3...というようにシェーダーからアクセスできるようにする。

もしくは、上記はちょっと特殊な対応なのでNvidiaのFXComposerを参考にしてもらえると分かりやすいのですがHLSLもそうですが他のシェーダーでもシェーダー側でそういったテクスチャパスの項目やパラメーターのUIを設定することが可能なので、それをメタセコの材質設定で反映できるようにする。
これならば、前者のような仮のSampler名を用意しなくても適切なSampler名として扱うことが出来、複数のシェーダーマップや設定項目が増えても本体側で対応する必要は無くのではと思います。（プログラマーではないので実質的にそうなのかいいきれませんが…）

廃止を含めて今後どうするか決まっていないと既に書いた通りです。
なぜ長文の質問がくるかは理解しかねますが、
少なくとも将来的な互換性に支障をきたしかねない可搬性の低い
仕様を取り入れることは基本的にはありません。

MQ3DLib.h/MQ3DLib.cppのMQObjNormalクラスを使う。
使い方はソース見れば一発