The issue is procedural. If you hate that code review of an API implementation might require changing the interface, then you should do a review of the API design before you implement it. That should be the case with every phase. Any time you have to perform multiple steps and worry that review of a later step might cause an earlier step to be invalidated, that simply means you're reviewing too late, at too coarse a level.
Or not. Adding more reviews keeps the big-O factor down, but increases the constant factor. As an organization, you can pick if you want individual contributors to never have to backtrack, or if you want them to be able to use speculative execution. One way is more predictable, and the other way can be faster if you're good at guessing right.