Perfect, thank you very much for that clarification!

That's not what the documentation says: redirect can be used inside route handlers, server components, and server actions: https://nextjs.org/docs/app/api-reference/functions/redirect

So I would like further clarification here. When should we use one vs the other, and what are the best practices?

I'm going to add some info myself based on what I've found.

redirect() throws an error which abords the route handler at the point it is invoked (effectively an implicit return). This could be problematic if you use it inside of a try/catch block, because your catch block will be called, which may not be what you want.

NextResponse.redirect in contrast has to be returned, and is a regular HTTP redirect response.

As for why you would use one over the other, I'm still in the dark. I don't know why redirect() is implemented the way it is.

redirect is implement this way for RSC, a React Server Component is rendered in the scope of an HTTP request that you can't see (and will never see because of layouts are implemented), but Next.js allows you to do some stuff like redirecting, getting headers or cookies

hence redirect()

yet Next.js also lets you do some usual backend stuff so manipulating an HTTP response, NextResponse.redirect() generates a 300 response for you, it's just an helper around JS Response object for convenience

However since it's dead annoying to have 50 APIs to do the same thing, even if they exist for a good technical reason, Next.js tries to make cookies/headers/redirect also consistent outside of React Server Components

so you can call them in middlewares also for instance, though technically you should have preferred "NextResponse.redirect"

Thanks for the explanation about the reason for the technical implementation @Eric Burel !

I think it would have been a better design choice to exclude redirect from places where standard response objects can be used. The exception thrown by redirect is a hidden implementation detail that is needed (as you say) because of the context it was created for, which makes it a questionable fit for things like route handlers. Why not simply say that to users?

I find Next consistently has this issue with its APIs - things are hidden or abstracted for the sake of simplicity or consistency, but that ends up making things confusing and causing baffling error output.

I think the core issue that creates all these underlying sources of complexity is the impossibility to just access the request in RSCs, because of layouts

I am expecting more interesting advances thanks to PPR, hope it might improve this area later on