Die Speicherung in UTF-8 ist ja ganz nett, aber je nach Implementation scheitert man dann spätestens beim Vergleich, wenn die zu vergleichende Zeichenfolge nicht auch UTF-8 ist.
In diesem Fall wird ggf. unter Verlusten in UCS2 konvertiert.

Auch der SUBSTR von UTF8 ist von der Implementierung abhängig.
Ggf. wird in UCS2 umgewandelt, der SUBSTR durchgeführt und in UTF8 zurückgewandelt.
Es kann aber auch schiefgehen.

Native UTF8/16-Zeichenfolgen werden eher im Programm in Strings (UCS2) vor der weiterverarbeitung konvertiert.

Ich habe da noch keine UCS4-Implemtierung gesehen, die dies alles korrekt behandeln würde.

Zumindest für die reine DB-Speicherung würde ich von UTF8 abraten.

Wobei Oracle generell NCHAR's als UTF-8 speichert und die Länge dabei in "Bytes" und nicht in "Zeichen" angegeben wird.
Also NCHAR(1) geht zwar, aber kann halt keine Sonderzeichen wie Umlaute aufnehmen.