Reason you are seeing the failure for this is following change from 2.5 in mmapmodule.c (:1109):

m_obj->data = (char *) MapViewOfFile(m_obj->map_handle,
				     dwDesiredAccess,
				     0,
				     0,
				     0);

changed to mmapmodule.c (:1414 in 3.3):

m_obj->data = (char *) MapViewOfFile(m_obj->map_handle,
                                     dwDesiredAccess,
                                     off_hi,
                                     off_lo,
                                     m_obj->size);

Previously size wasn't passed to MapViewOfFile. Passing new size to MapViewOfFile greater than the size of previous map causes an error. 

This seems to be by design. From MSDN:

MapViewOfFile:

dwNumberOfBytesToMap [in]
The number of bytes of a file mapping to map to the view. All bytes must be within the maximum size specified by CreateFileMapping. If this parameter is 0 (zero), the mapping extends from the specified offset to the end of the file mapping.

CreateFileMapping:

lpName [in, optional]
The name of the file mapping object.

If this parameter matches the name of an existing mapping object, the function requests access to the object with the protection that flProtect specifies.

So on second call, CreateFileMapping will get back the previous mapping object, which has 4096 bytes of memory mapped. MapViewOfFile will try to map beyond its limit and get an error.

I am curious how "resizing" worked before. I tried passing size=0 to MapViewOfFile on second call (length=8192) then call VirtualQuery on the returned map, which can query the size of the buffer. Size is still 4096. So even if length=8192 and we call CreateFileMapping with this length, it will return the previous 4096 byte-buffer.

This looks to me like an issue which existed until Python 2.5, namely this error was silenced and returned map was still 4096 bytes, just claiming to be 8192. The way it is behaving now seems to be the correct way.