Here are my comments on the other parts of the patch:

Python/structmember.c

The existing code is safe, but would silently produce wrong result if
T_CHAR attribute is assigned a non-ascii character.

With the patch this situation will be detected and an exception raised.

I am not sure that would be a desired behavior of py3k.  I could not
find any examples of using T_CHAR member in the stdlib, but an
alternative solution would be to change T_CHAR code to mean
PY_UNICODE_TYPE instead of char member.

Objects/typeobject.c

"%s" -> ".400s" is an obviously good change. 

The existing __doc__ processing code is correct.  Proposed code may be
marginally faster, but will allow docstrings with embedded null
characters, which may or may not be desirable (and may break other code
that uses tp_doc). Finally PyUnicode_AsStringAndSize always returns
null-terminated strings, so memcpy logic does not need to be altered.


Objects/structseq.c

Change from macros to enums is purely stylistic and python C style seem
to favor macros.

I don't think a repr of a python object can contain embedded null
characters, but even if that were the case, the patched code would not
support it because the resulting buffer is returned with
PyUnicode_FromString(buf).


Modules/datetimemodule.c

Existing code compensates for an error in initial estimate of totalnew
when it checks for overflow, but the proposed change will make code more
efficient.

Modules/zipimport.c

Since 's' format unit in PyArg_ParseTuple does not properly support
unicode yet, it is hard to tell if the current code is wrong, but
unicode paths cannot have embedded null characters, so use of 's#' is
not necessary.

Modules/timemodule.c

Supporting format strings with null characters is probably a good idea,
but that would be an RFE rather than a bug fix.

Modules/parsermodule.c

Looks like there is a bug there.