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.