In your string ë is a single code point, e with diaeresis Unicode Character 'LATIN SMALL LETTER E WITH DIAERESIS' (U+00EB)
In the problematic example it is a lowercase e Unicode Character 'LATIN SMALL LETTER E' (U+0065) followed by a combining diaeresis Unicode Character 'COMBINING DIAERESIS' (U+0308)
Try copy-pasting the string from the post and you should get the result you're looking for.
Yep, I know what you mean, but it seems that Safari is possibly normalising the "ë" into a single grapheme [<- should be code point], which it couldn't do for the IPA-ish string I posted. If I copy the input into my terminal it's two code points as expected, but when I run the example it's been re-interpreted into a single code point, even if I paste the string individually. Weird.
EDIT: Yep, it's Safari. Firefox is doing the expected thing and properly preserves the "ë" as two graphemes [<- another on-the-house "typo", it's Friday], hence misplacing the non-spacing mark for the output.
EDIT2: I guess this means Safari is using NFC?
you mean "two codepoints"?
Ha, busted! Yes, of course I do. 
So if I understood correctly, the main "problem" of the last 30 posts is that OP feels Unicode support in the standard library is not sweet enough (as in "not enough sugar").
As other pointed out: if you handle text, use a crate that does the right thing for you or write a function that does what you want. There are good reasons this is not in stdlib and there are solutions providing all the user-friendliness you want.
It's too bad that @jzakiya has disengaged with the discussion. I would have liked to ask if there was any other example besides string reversal that would demonstrate the point. We got kind of stuck on that one thing.
Personally I think that the Python programming language has the most readable code I've seen anywhere. But it's slow. You can use Cython to compile it to C, but the speedup isn't huge. In order to make Cython run significantly faster you need to add type annotations and "cdef" keywords and the like. At that point the code becomes more verbose and (IMO) less readable.
Given that anything other than pure Python is a step down in readability for me, I'm willing to trade some readability for speed and correctness, or I wouldn't be here. My hope is that as I get more acquainted with Rust the extra verbosity will be less of an issue for me.
Some of the complaints against Rust's usability are that it isn't "batteries included" (doesn't have a large standard library) like Python does. However, I suspect that if Python were invented today it too would not have a "batteries included" library. When I first started using Python more than 20 years ago, there was nothing like the Comprehensive Perl Archive Network (CPAN) nor pypi, npm, etc. So the batteries included approach made more sense and saved a lot of trouble. Nowadays crates.io seems like a reasonable solution to the problem of "the core Rust language doesn't have a function I want/need".
@moderators would it make sense to close this topic?