As discussed (briefly) over email, I'm moving this discussion back to the Python-3000 mailing list.  But before I do I wanted to clear up something from your reply.

"lazy concatenation" and "lazy slices" are really two patches, filed under the "lazy slices" penumbra.  They are different optimizations, with different implementations and different behaviors.  I implemented them cumulatively to save work because they intertwine when merged, but I had hoped they would be considered independently.  I apologize if this point was unclear (and moreso if it was a bad idea).  My reason for doing so: I suspected "lazy slices" were doomed from the start; doing the patch this way meant wasting less work.

One downside of "lazy slices" is their ability to waste loads of memory in the worst-case.  Now, "lazy concatenation" simply doesn't have that problem.  Yet the fourth and fifth paragraphs of your most recent reply imply you think it can.

A quick recap of lazy concatenation:
  a = u"a"
  b = u"b"
  concat = a + b
"concat" is a PyUnicodeConcatenationObject holding references to a and b (or rather their values).  Its "value" is NULL, indicating that it is unrendered.  The moment someone asks for the value of "concat", the object allocates space for its value, constructs the value by walking its tree of children, and frees its children.  The implementation is heavily optimized for the general case (concatenation) and avoids recursion where possible.

The worst-case memory consumption behavior of lazy concatenation is adding lots and lots of tiny strings and never rendering; that will allocate lots of PyUnicodeConcatenationObjects.  But it's nowhere near as bad as a short lazy slice of a long string.

Does that make "lazy concatenation" more palatable?