It looks like all cpu must be updated first to do a not too expensive transition.
Changing all cpu/periph/gpio.c to make this work to only after re-migrate them may be overkill.

I could merge the first commit updating the documentation directly though if you want to split.

It looks like all cpu must be updated first to do a not too expensive transition.

yes, and that is exactly what I meant beforehand: just doing this half-done step in the API change, just because "I don't want to/don't have the time to do it right" leaves a mess for other people down the line. So either we do it right, or we might as well leave it be... I really don't like this hacky 'now a bit and the rest maybe later' approach.

Seems like #9981 needs be merged before this one.

Again: we need to be more careful when doing these kind of API changes. If not done cleanly, it always causes a lot of trouble down the line, and these things must be caught by the reviewers! So next time...

IMO you're exaggerating quite a bit. This was not some deep API change, just a move towards more modularization. It is perfectly acceptable to implement such a change within the build system, but only provide an implementation that makes use of it in just one (or even none) of the platforms.
Before #9845, all platforms implicitly provided the feature, though some through stubs. After #9845, the same, but one step further towards not providing it if it is not implemented. Code that was boken before was still broken after. Now it is possible to incrementally add this optimization to more platforms.

I think this was one of these small, incremental improvements that could've been stalled by premature aim for perfection. Luckily this time, it didn't.

Further more, the changes in #9845 made the function documentation for gpio_init_int disappear from the generated documentation.

That's unfortunate. Thanks for fixing. ;)

Why would #9981 be needed for a simple documentation change?

reduced the PR to the docfix, and will open another one for the scope fix.

Why would #9981 be needed for a simple documentation change?

Not for the doc, but for the scope fix... But not relevant for this PR anymore - yes, I got it :-)

IMO you're exaggerating quite a bit.

maybe a little bit, its just the frustration that kicks in when I see so many things only done half-baked. I definitely see the advantage in doing things in small incremental steps, and thats how it should be done. But for many tasks, people tend to leave it at that state and the adaption process stalls half way, always leading to some non-core users being utterly disappointed about the implementation state...

So I think for deep and/or complex changes this is perfectly fine. But for a simply change as targeted by
#9845, one can easily do all the adaption at once and be done with it (of course I don't mean putting it all in 1 PR...). For this particular change, the actual code changes to all 16 effected CPUs did take something around 10min... The actual work is to create all the clean commit and PRs :-)