UNICODEが・・というよりも、ShiftJISに絡む問題になるのですが、一般的にShiftJISと呼ばれる文字コードは文字の集合自体がOSや環境で微妙に異なります。そのため、それぞれの集合ごとにUnicodeと変換するための定義（マップ）も微妙に異なります。
元の定義をほぼそのまま実装している、通称「SHIFT_JIS」の集合。
MS-Windowsで使用されている、「MS932」「CP932」「Windows-31j」の集合。
MACで使用されていたもの。sjis-macとかそんな名前がつくことがある（あまり出番が無い）の集合。
世の(ユーザが触れる)OSの大半がMS-Windowsであるために、MS932にことをShift_JISと呼んでいても、間違いとは言えません。
これらの集合は、大多数の部分は共通なので、間違えていても問題が発生しない場合がほとんどです。
化けてしまうのは、大半は、共通ではない特定の文字を含んでいて、
（Ａ）変換する元として指定する時に、MS932の内容をSJISとして他のコードに変換した場合と、
（Ｂ）MS932から他のコードに変換した内容を、(MS932ではなく)SJISに戻そうとした場合
です。
（もちろん、ＡでもＢでも、MS932とSJISの位置が逆でも化けます。念のため。）
なでしこの場合、集合の使い分けが少しややこしく、以下のようになるようです。
※「あ」のマッピングはどれでも同じなので実質、差はでません。
・UNICODE変換のように、入力側の文字コードを自動認識させて変換する関数は、上記の中では「SHIFT_JIS」として扱われます。
（『「あ」をUTF8変換』とした場合、SHIFT_JIS→UTF8のマップが用いられる）
・入力側の文字コードが関数名に含んでいる関数の場合、「MS932」として扱われます。
（『「あ」をSJIS_UTF8変換』とした場合、MS932→UTF8のマップが用いられる）
・入力側の文字コードを引数で指定できる場合、明示的にどれでも指定できます。
（『「あ」を「SJIS」から「UTF8」へ文字コード変換』とした場合、SHIFT_JIS→UTF8のマップが用いられ、『「あ」を「MS932」から「UTF8」へ文字コード変換』とした場合は、MS932→UTF8のマップが用いられる）
Windows方言のSHIFT_JIS(MS932)と断定できる要素が無い限りは、１番、標準仕様に近いものとして扱うというのは、１つの方法です（共通した文字が多すぎて、自動的に判別することは不可能）。なので、なでしこの現在の仕様ではそのとおりということになると思います（正しいかどうかは分かりませんが、「確実な正解」は無いと思っています。）
この微妙な問題に絡まないようにするためには、自動認識に任せずに、常に明示することで、回避できます（自動認識の限界なのでどうにもならないため。）
（Unicode変換だと明示できないので文字コード変換使うことになります）