I don't like working with strings as they tend be highly important and memory-consuming by nature. However, this is only partially true - especially considerung that I'm used to null-terminated strings from C. Another concept I didn't realize until I read about it to have the first character of a string to be the number of elements in this string. This may be a good idea, not having to count string length and so on, but it also makes string definitions in C very umcomftable as you'll always have to count before using it.
Anyway, both concepts have very interesting advantages. The classic C string makes high density code in C itself along with a whole range of processing-only algorithms that don't need to care about counters or length limiters. Also, splitting strings does only require placing a null somewhere compared to length-terminated strings where you need to know where the string starts to correct it's previous size before inserting the new size. Ultimately, you can have very longs strings that don't have to care about how big the string length type is. You don't need to insert connector elements that lengthen string and you don't need to care about the final length if you create/write one - static or dynamic.
But no let's talk about the good things about lengtg-terminated strings: fast (re)allocation for concation, very quick length iteration (even with 256 byte chunks for 8bit chars), quick iteration over many sequentially stored strings and conversion from symbol-seperated strings with later iteration, same iteration as with array, no need to double-check string content on iteration as well as very well-defined string bounds for related functions.
Both are equally powerful constructs and I might consider doing a rewrite of string.h in case that they might come in handy for some stuff. Just thinking about my LegoNXT and it's tendency to be very, very slow. In the end it might be faster to do string operations this way, though your compiler can't optimize it out.