I like the turtle one. Although I feel like with a minimal number of commands really wants the ability to define new ones.
like a:[xyz] defines further instances of a to be [xyz]
I think the thing that makes me want it is that it takes a loop 3 deep to recover the characters used to define it.
CC is shorter than [C]
and
CCCC is shorter than [[C]]
It's not until CCCCCCCC that [[[C]]] provides a gain. but that's also [[CC]] or [CCCC]
Unless you wanted to define things more literally. If you allowed a user defined a to be a literal [[[ and b to be ]F] then you could make some truly incomprehensible programs where it would be nigh on impossible to keep track of the nesting. Sick, but entertaining.
CC[[[[[[[[[FFF]FR]FR]FRS]FSR]]]][[FR]]CRRRFR[RFRRR[[[[FFF]]]]]CCCCCCC[[FF]]CCCCCCC[[[F]F]F]CCCC[[[[[[RF]FFR][[[F]]R]R[[[FS]]RS]]]]
[update]
Late thought alternate theory. Byte pair encoding to create additional instructions.
a:bc defines a to be bc
so <:[[ and >:]] would define < and > to be double loops (while looking like bert and ernie smilies to boot) but more importantly you'd get some deliciously evil options like
X:RR // X becomes RR
Y:XX // Y becomes XX which is RRRR
Z:XY // Z become XY which is RRRRRR
L:ZR // L becoomes ZR which is RRRRRRR which is 7 rights So L is now one left
but if redefinition were allowed then A:B: would mean ACD would define B to CD and ADC would change B to DC. I did a few scribbles of ideas and I think there's a ridiculous amount of overly complex power in there.