愚痴です。
v2.1で実装されたマクロ専用関数の引数定義が
「なんかおかしくね？」というネタなので、
大多数のユーザーには関係のない話かと思います。

CClipboard::GetClipboradByFormat
CClipboard::SetClipboradByFormat

nMode -2:通常のサクラの処理, -1:バイナリモード, それ以外:文字コード
nEndMode -1:文字コードに依存 0:GlobalSize 1:strlen 2:wcslen 4:wchar32_tの文字列

nMode==-2は良いのです。
通常のサクラ＝unicode、ですから。
nMode==-1が存在する理由と、文字コードの意味が分からんとです。

windowsはCF_UNICODETEXT形式が存在する場合、
CF_TEXT形式を要求したUNICODE非対応アプリに対して、
ACPによる自動変換を提供します。
つまり、自前で変換する必要はありません。
自前で変換してCF_TEXTを突っ込むと副作用もありますし。

サクラはwindowsロケールが対応しないコードページの、
いくつかに対応しています。(JisとかEucとかUnicodeとか)

SetClipboradByFormat("美乳", "CF_TEXT", 2, -1)
※"美乳"はEUCにしか存在しないコード値を持つ。

とした場合、windowsはCF_TEXTにEUCの"美乳"を突っ込みます。
この状態でCF_UNICODETEXTを要求した場合、
windowsによる自動変換は"ja-JP.932"で行われます。
当然、化けますよね。。。
アプリの作りとしては、windowsロケールが対応しないコードページを使っている場合には、引数指定をガン無視してUNICODEで突っ込む対応が必要になるような気がするのです。

でも、そうすると引数の存在意義が…
「意味わからん」というのはそういうことです。

nEndModeについては存在意義が不明です。
CF_TEXTとCF_UNICODETEXTを指定した場合のデータサイズは、
それぞれcharとwchar_tのNUL終端までと決まっています。
これはWindowsAPIの仕様なので勝手に処理してはいかんです。
windowsロケールはunicodeファミリを扱えないので、
UTF32を扱うにはUTF16BEに変換し、unicodeとして突っ込むべきです。


ググってみた感じだと
nMode=0(SJIS)、
nEndMode=-1(文字コード依存)
で使われているみたいです。
※このマクロ関数が実装されてるのはv2系なので
　常に無駄な変換(U→A)が発生するが、
　windowsが勝手に登録するCF_LOCALEは矛盾しないので問題ない。

取得、設定するデータに「文字列以外」を扱えるなら
別な突っ込みになるんですけど、
定義を見る限り、第一引数はVT_BSTR想定だし。。。

第一引数がVT_ARRAYを受け付ける前提で、
nMode==-1(バイナリ)、かつ
nEndMode==0(サイズをGlobalSizeで取得)な場合だけ
意味があるnEndModeの存在意義。

かと言って、VT_ARRAYにして
CF_DIBとか使えるようにしたとして、
そういうマクロを書く人がいるのかどうかとか、
すっごく微妙。。。