I should mention that I did discover some source code on GitHub, presumably for this wrapper module, and I believe I found a few questionable parts in the logic for this library that may help explain the cause of this problem:

https://github.com/python-git/python/blob/master/PC/_msi.c

Here are some snippets from the summary_getproperty function that may help:

    char sbuf[1000];
    char *sval = sbuf;
    DWORD ssize = sizeof(sval);

First, here, I believe the ssize value is not going to be initialized as one would expect at first glance. Since sval is a pointer and sizeof() returns the size of it's parameter, in this case a pointer, ssize will represent the pointer size on the target platform. In this case, on a 64bit OS, it's likely going to be set to 8, which I suspect the expected value for ssize is going to be 1000 - the size of the static array sbuff.

    status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, 
	&fval, sval, &ssize);
    if (status == ERROR_MORE_DATA) {
	sval = malloc(ssize);
        status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, 
    	    &fval, sval, &ssize);
    }

Now, in this snippet it tries to load the string value from the file, and if the input buffer is not of sufficient size it reallocates the pointer to an appropriate size. Given the fact that ssize is probably initialized to 8 (or less) it is pretty safe to assume the first call to MsiSummaryInfoGetProperty changes this value to the length of the data stored in the file. Closer examination of the documentation for this Windows API function reveals that in this case ssize will be set to the number of characters required 'not including the terminating null character'. (http://msdn.microsoft.com/en-us/library/aa370409(v=vs.85).aspx)

    result = PyString_FromStringAndSize(sval, ssize);

Then finally I noticed this function call. I suspect the problem may lie here. I'm not too familiar with the Python SDK but it sounds like when using Unicode strings - as all string are in Python 3 - you are supposed to use PyUnicode_FromStringAndSize instead. So perhaps there might be something getting lost in the translation, either via the use of this function or perhaps subsequent marshalling of the string object into the Python runtime, due to the encoding changes... not sure. It could be something as simple as one of the function calls used therein assume that the 'size' count includes a null-byte while others don't. It's hard to say without digging into the libs some more.

I hope this helps.