You probably already on it, but the thing that rubs me wrong about this, is that all of these places shouldn't exist to begin with, I think.

Replacing the finally action with a full-blown RAII pattern will be an improvement! But the thing is that for example this block is useless and because of this obfuscating what is simple into something that seems difficult, IMO.

unique_* are called with the GIL held and defensively ensuring we hold it just obfuscates the code, one could assert that if we must, but that would be the most
.
Now, there is the annoyance that we release the GIL twice within the function, but that is still far better done via:

// code with gil
{
    no_gil release via RAII
    // code without GIL
}
// code with gil
{
    no_gil release via RAII
}
// code with gil

Somewhere along the line, what was simple enough restoring either got messed up and then apparently these defensive GIL ensuring things were added.
As a rule of thumb though, defensively grabbing the GIL only makes sense for setting an error, and we even have npy_gil_error() for that.

In my next update, I will have a (very conventional) RAII class that wraps PyEval_SaveThread() and PyEval_RestoreThread(thread_state) using the same constructor/destructor pattern as EnsureGIL, which I think is what you are suggesting above.

I agree that if we are sure the various unique functions are always called with the GIL (which is reasonable--unique is not a ufunc, after all), then the current use of NPY_ALLOW_C_API, etc, in there is unnecessary. I'll remove that in the next update.

My updates in unique.cpp are becoming nontrivial: in addition to removing the use of the macros related to ensuring the GIL (NPY_ALLOW_C_API, etc) and adding the use of RAII objects for PyEval_SaveThread/_RestoreThread management, there is some incidental DRY clean up and encapsulation that works out nicely. That's not a problem, but these changes will cause big conflicts with @math-hiyoko's recent PR to use a hash map to implement the various return_ options of unique (#30110). I haven't looked at that PR closely yet, but if it looks good enough to eventually merge, we should get that in before I pursue my PR here. I suspect that at least some of what I am thinking of changing could be incorporated into #30110.

Thank you for the consideration.
#30110 is still under active development and there are several parts that I plan to revise, so waiting for it to be completed might delay this PR.

I would prefer to have this PR merged first, and then update #30110 to incorporate the changes from it.

OK, thanks @math-hiyoko. I'll continue working on this, and keep an eye on #30110.