I have not yet tried for ustring, it's a good idea.  I'm not especially hopeful, though; I don't expect that ustring construction (versus comparison and copying -- which don't need to lock its internal hash table) is something that we have any significant contention on during a render.

Revisit for customization or other work -- definitely!  One bit at a time. :-)  I'd like to make this large improvement, get things stable, and branch a stable 1.2 fairly soon.  This by no means marks the last time we revisit performance of the texture cache.  In fact, there are at least two (post-1.2) areas I'd really like to visit: (1) alternate cache replacement policies, as you and I have discussed offline (which may or may not be able to use this data structure, and may or may not be amenable at all to heavy multithreading), and (2) I've been cooking up some changes to the ImageInput API that make the ImageInput itself much less stateful and will allow the ImageCache to hold the mutex on each individual ImageInput for a shorter length of time.