Rationale

text, rope Are Implicitly Convertible from `char const *`.

I find that the syntactic overhead of bringing UDLs into scope and then using them to be too high in some cases. Aggregate initialization including string-like objects is one of those:

Table 1.9. Explicit vs. Implicit Conversion from `char const *`

Explicit	Implicit
using namespace boost::text::literals; std::array<boost::text::text, 3> = {{ "foo"_t, "bar"_t, "baz"_t }};	std::array<boost::text::text, 3> = {{ "foo", "bar", "baz" }};

Explicit

Implicit

using namespace boost::text::literals;

std::array<boost::text::text, 3> = {{ "foo"_t, "bar"_t, "baz"_t }};

std::array<boost::text::text, 3> = {{ "foo", "bar", "baz" }};

I find the implicit-conversion code much more natural.

The behavior of some of the Unicode algorithms is intended to be tailorable. Boost.Text provides customization of some of its Unicode algorithm implementations for this purpose. Some possible tailorings are not available.

Grapheme breaks are not tailorable, because they are fundamental to how a large part of Boost.Text operates; everyone must have the same sense of what a grapheme is for this to work.
Word breaks are tailorable. The tailorings available via Boost.Text's word breaking API should be enough handle most of the shortcomings listed in the word break notes in Unicode Text Segmention. The shortcomings not covered by Boost.Text's API require dictionary lookups (very much out of scope) or extra code point properties (for breaking on script boundaries; also out of scope).
Sentence breaks are not tailorable, because the suggested tailorings require a large amount of context, and possibly dictionary-style lookups.
Line breaks are not tailorable, because all the suggested tailorings involve multiple modes of behavior (e.g. for Korean text) or dictionary lookups.
For bidirectional ordering, Unicode lays out certain tailorings it refers to as Higher Level Protocols. Boost.Text directly supports HL1 and HL4. HL2 is unsupported because it frankly doesn't seem very important. HL3 and HL5 can be accomplished by manually adding directional formatting characters or other desired code points to segments of text. HL6 is completely unsupported, because it also seems like a very low-frequency use case.

Boost.Text Does Not Use allocators

Allocators are too low gain for the cost they impose. How many std::basic_string template instantiations in the code bases of the world involve a non-default allocator? I would be surprised if it was as high as 1%. Allocators may once have served an important function, but in modern C++ are a perfect example of not sticking to "Don't pay for what you don't use."

As a concrete example, consider std::vector. This is a type whose sole purpose is to manage the allocations and reallocations of a heap-allocated array for you. Its interface allows me, via its allocator template parameter, to change its behavior to be a stack-allocated array of fixed size, but with a std::vector interface. This has a large impact on the properties of the type, the noexcept-ness of and time complexity of swap() to name just one. I don't consider this to be a feature of the std::vector design, but a bug.

Rationale

text, rope Are Implicitly Convertible from char const *.

Unicode Algorithm Tailoring

Boost.Text Does Not Use allocators

text, rope Are Implicitly Convertible from `char const *`.