I can't seem to find the right discussions, but I believe forbidding this was a conscious decision. I did some work on this on #5508, which I believe @ahaldane picked up. #6562 may also have some information to what was done, but I have trouble understanding what the exact situation is right now.

So, your PR is a bad idea because it extends deprecated behaviour! Choosing the axis based on stride is a bad idea, which I suspect is why that behavior on Fortran arrays is now deprecated. This pr still only chooses the last axis.

@ahaldane's stuff I've seen and worked on elsewhere, but I don't think it's relevant here.

Oh, your PR raise s that this needs a special case when a dimension is size 1

I'm just saying that in the release notes of 1.11.0 we advertised the current behavior:

https://github.com/numpy/numpy/blob/master/doc/release/1.11.0-notes.rst#future-changes

So we should probably understand why that decision was taken before backpedaling on it.

The decision in 1.11 was the deprecation I mention in the issue this fixes. This isn't a backpedal, as the Fortran case continues to be deprecated, and the other cases were absent long before 1.1

You're right though, the rationale used for that deprecation can probably be applied to this too.

Think of a 2D sliding window type of view, where both axes have the same stride. The array is not contiguous, but its last dimension is. Say the array is of doubles and you take a complex dtype view of it. What do you do with the stride of the first axis? Leave it as is? Transform it like the last axis one? Whatever you do, it's going to be surprising to some users, hence probably better not to do it.

You could define something like "weak contiguousness", where the stride of each axis is required to be a multiple of the product of the size and stride of the next one, which would cover all arrays that are slices of contiguous arrays. And allow views like these to be taken on "weakly contiguous arrays with a strongly contiguous last dimension" only, probably with no issues like above. Not sure the benefit is worth the extra complexity.

Let's move discussion of this to #9496. I'm gonna close this PR, and file another that's just the MAINT part for now (#9499).