With #16413, many defaults regarding HTTP caching policies have been updated to the latest standards.
By default, RedirectViews have http10Compatible set to true, which means that they use HTTP 302 as a default HTTP response status. Setting this property to false make RedirectViews use HTTP 303 by default.
Now when set to false, RedirectViews don't use the RESPONSE_STATUS_ATTRIBUTE request attribute as a response HTTP if it is available. Both configuration choices should behave the same regarding to this request attribute.
I've looked at this and this actually bothers me.
I've tried just changing the default value in this draft commit.
I'm fine with always making use of the redirect attribute, which is the main driver fir this issue, as explained in #17789.
But as explained in the draft commit, changing this default value also changes the default HTTP status used for redirection.
Instead of using HTTP 302 Found, HTTP 303 See Other is used. I think this status has been chosen because HTTP clients tend to rewrite the method, which is not supposed to be the case with 301/302:
POST /resource -> HTTP 303 Location /other -> GET /other
I've updated the issue description and for now I'll go with just the request attribute support.
Nowadays, 302 and 303 behave the same and are both accepted by the latest RFCs. There's no need to deprecate this right now.