The intermediate view may not be a big deal, but yeah, it's definitely nice to skip it!

but I thought I would get some opinions on whether this is the right direction at all before doing that. Though opening as draft for now

I like this in principle, but I think there are two subtleties, and unless we shrug them off (probably OK, but...), I am actually not sure there is a clean solution:

• I think PyArray_View() diverges from .view() here, and I am not sure that it still works as well as it should with this change (without fixing __array_finalize__ there can be regressions, e.g. MaskedArray itself could have one in theory.).
• It would be nice to keep .dtype = work with a DeprecationWarning to not break existing implementations.

Now, I can see calling obj.view() from PyArray_View() if it exists, while arr.view() would of course not and (try) call .dtype = (arr.view() would be the current implementation).
In that scenario, I think we get:

• def view() can be used to avoid the .dtype = setting (but it may be a bit inconvenient).
• If delete .view() you can push all logic into __array_finalize__, which may make a lot of sense. (But MaskedArray is interesting as it adds a kwarg, so we can't delete it.)

So, in my approach _set_dtype sticks around indefinitely, while in this .view() does, but may not be used.

With _set_dtype we could eventually deprecate and force transitioning to __array_finalize__ only, but it's a two step thing. (I am not actually sure we can if we promise to call .view(), though.)

But too much text, not sure what it gives us. To me using _set_dtype is still the easier choice probably. But if we either disregard the above problems a bit or like the PyArray_View() calling subclass.view() as the final state for sure, then I think this is better.

@seberg - I've adapted this follow-up, where just one view is done for the "standard in the future" path. Note that I got carried away a bit in my reorganization of the code, which makes the difference view rather poor. You may want to just look at the file directly... (I do think it has become clearer as a result, in particular by just putting the path of the future first...)

Nice, so this "just" re-organizes the double view. I'll have a look, moves things around, but I think otherwise I'll probably just put it in unless I find an issue.

(I have a "more complete fix (TM)" for the deprecation, almost lined up, but might just put this in and rebase. it's a bit ridiculous and of course nothing is really 100%, but considering how important the .dtype assignment deprecation is in a sense...)

MacOS / Accelerate warning would seem unrelated...

@seberg - sorry, looking at it again, I felt I could clean up the addition a bit more, so I did... Should now be truly ready for final review.

Agreed with all changes, thanks!