Almost no backend stores the keys in UTF-16 (Windows, maybe?), and even then, they don't do so using QString. So using QStrings as keys is quite counter-productive, because the typical ASCII key first gets converted to UTF-16 on the heap, then back to ASCII (or a superset thereof) for persisting. A QAnyStringView as the key type can thus a) avoid re-coding the charsets and b) compactify the calling code, as usual, by not having to construct and destruct a QString.

This task is just about the user-facing API. The natural follow-up task is to remove the UTF-16 middle-man and convert the QAnyStringView to the backend's native encoding directly, but that likely requires QAnyString.