IMO, it's better to correct API design errors early, rather than going
through a deprecation process.

Note that PyUnicode_AsString() is also different than its cousind
PyString_AsString(). 

PyString_AsString() is mostly used to access the char* buffer used by
the string object in order to change it, e.g. by first constructing a
new PyString object and then filling it in by accessing the internal
char* buffer directly.

Doing the same with PyUnicode_AsString() will not work. What's worse:
direct changes would go undetected, since the UTF8 PyString object is
held by the PyUnicode object internally.

Even if you just use PyUnicode_AsString() for reading and get the size
information from somewhere else, the API doesn't make sure that the
PyUnicode object doesn't have embedded 0 code points (which
PyString_AsString() does). PyUnicode_AsString() would have to use
PyString_AsString() for this instead of the PyString_AS_STRING() macro.