【バグは続くよ、どこまでも】シリーズから始まったUnicode LRM（U+E200）←→SJIS変換のゴミ（'?'）対策は、基本的にASCII "char"ベースのBCCSkeltonクラスを、Windowsが内部的に使用するUTF-16の"WCHAR"ベースに書き直したBCCSkelton-WCVによって解決されることになりました。（注）
注：「元々WindowsがUTF-16ベースなんだから、ファイルパス、名もUnicodeで書けば問題ないんじゃない？」というご主張もあるかと思いますが、「ファイルパス、名に、必要性が無ければ余計なコントロールコードを入れない」という方針は正しいし、そのコントロールコードがコード変換の際に不可逆性を有するなら、それを除去することは正しいと今でも思っています。特にこの「U+E200が混入」した原因が、意図せざる日付データのコピーによるものであり、更に真であると考えます。
当初は「禁則文字'?'の混入－バグ」と理解していましたが、結局はUTF-16コードがSJISへ変換される際に、対応文字が無い場合'?'に変換されるという仕様であると考えられ、FileNameCleanerの新しい仕様は「Unicodeの一般句読点記号（U+2000～U+206F）の、ファイルパス、名への意図せざる混入の発見、除去」としました。
先ず、チェック対象のフォールダーを「選択」ボタンで特定します。するとファイルパスがチェックされ、Unicodeの一般句読点記号があるか否か、いくつあるか教えてくれます。またEDITボックスにそのファイルパスが表示されます。（注）
注：EDITボックスにSendMessageW関数でUTF-16文字列を送った際の表示ですが、SJIS変換されているようです。
「はい」ボタンを押すとフォールダーのファイルパスからUnicodeの一般句読点記号が除去され、次にこのフォールダー内のファイルをチェックします。（変換直後はまだ'?'が残っています。）
同様にファイルの中のUnicodeの一般句読点記号がチェックされ、「はい」ボタンで除去されます。（この段階ではフォールダー名が更新され、'?'が除去されています。）
最後の（このサンプルでは3つ目の）ファイルで、SHFileOperationのエラーメッセージが出ます。何故か名前変更ファイル名にワイルドカードが使われたような反応ですが、それはない筈です。「スキップ」ボタンを押してみます。
Rename処理されたファイルのオリジナルファイル名がリストされます。（'?'がありますね。）
最終ファイル名の表示を行うと全てのファイルから'?'が除去されており、別途Explorerで調べても全て除去されています。（従って先ほどのエラーメッセージと「スキップ」は何をスキップしたのかよく分かりませんね。→一応コードを見たら、do {～} while();ループを使っていたので、while() {}に替えたらエラーメッセージダイアログは消えました。）
ということで、所期のプログラムの完成です。