1 - See note for 3 below for probably the most significant difference when moving to memoryviews.
2 - With standard Cython numpy array types, `.shape` is still stored as a Tuple and thus can be understood as a Python object. This appears to be no longer the case for MemoryViews; it now is a vector of `Py_ssize_t` and Python can't understand this. If you had e.g. `cdef Py_ssize_t[8] shape = image_zxy.shape` this would work, I believe. The problem isn't the `.` operator, it's that you are assigning to a non-`cdef`ed object which Cython will only allow if it's a Python object. I have no idea why it has 8 elements. Does anyone know if this an inherent dimensionality upper bound in NumPy or Cython's memoryview implementation? Are all of the elements zero above the highest dimension? We'll probably never touch 8 dimensions, but these questions are important.
3 - I think the rest of the compilation errors can be explained by this note in the [Cython Memoryview docs](http://docs.cython.org/src/userguide/memoryviews.html) (emphasis mine):
> **Memory layout**
> The buffer interface allows objects to identify the underlying memory in a variety of ways.
> **With the exception of pointers for data elements**, Cython memoryviews support all 
> Python new-type buffer layouts. It can be useful to know or specify memory layout if the
> memory has to be in a particular format for an external routine, or for code optimization.

I'm not intimately familiar with memoryviews, but it appears pointers to `arr.data` elements don't play nice with them.