I have been meaning to have a closer look at that library for weeks now, but unfortunately I don't sem to find the time to do so. So I'm just writing down some thoughts: First of all, I hihgly support the inclusion of this library into boost (assuming there aren't any major design problems). C++ needs unicode support easy text processing - the former being a prerequisite for the latter. The only way we get those things into the standard is if the different approaches get battle tested in anger, in real-life projects. What the average programmer like me (who is not working on a text editor) imho needs is the ability to read text from one interface, do some basic input validation, normalize it, (potentially) split it up and or parse parts of it, store other parts through a different interface, retrieve all of that later and send it on through a different text based interface. During all that I don't want to have to worry too much about whethernon-asccii text got broken in betweeen. And in particular I should not have to worry about the particularities of how unicode works to o that. For that, I think it is much more important to have encoding aware interface types and easy to use transcoding functions than a full set of unicode text processing algorithms. Not that I'm not happy when they are there, but at least for the standard, lets please focus on what standards are for: Facilitate and enable components from different 3rd pary vendors to work seemlessly together! I'm also very happy to see that the library focuses on the 90% cases instead of trying to be flexible enough to be usable for every possible use case and under every possible circumstance. Best Mike