We've already used move/r-value-references in several places, but not
for string arguments.
I guess we might start taking std::string_view with C++17 instead of
std::string and this might largely take care of this.
I don't see how string_view would make any difference to whether or not we end up copying strings. Can it?
Separately, how would string_view interact with Glib::ustring? Glancing at the available documentation, my guess is "it wouldn't", since it seems to be based on fixed-width characters, not to be context-sensitive. So it may not be a suitable replacement for ustring.
The more basic point from the latter question is that it's unbelievable we still don't have a real Unicode string type in C+ itself. I guess now that we're finally getting things like standardised filesystem and networking support, surely adequate Unicode handling can't be too far behind... I also note with interest the prospective graphics library, which was to be based on Cairo last time I looked.
Anyway, I think the ability to move strings or anything else in most cases will ultimately depend on the C libraries, and I think they rule it out. It's probably ultimately unimportant; I just tend to hate passing strings around in my own code and try to forward-then-move them all the way (leading to some private APIs that are probably horrifying to purists) so this idea came into my head and had to be typed out. :)