OK, I think I finally see what you're getting at.  These are values which, in the general case, one wants to specify on a connection-by-connection basis rather than a request-by-request basis or an entire-session basis, so abstractly they are not part of the request.

The problem I am trying to solve here is that even if you have set defaults at the session level, if you're doing manual redirection processing you have to re-specify them in each call to `Session#resolve_redirects`, because it doesn't replicate `Session#send`'s logic for pulling the defaults out of the session. Moreover, if I needed adapter-specific connection options, those would be being applied only to the initial request, because, at present, `Session#send` passes *arbitrary* keyword options down to the adapter, but does not preserve them for subsequent redirects, and `Session#resolve_redirects` does *not* take arbitrary keyword options. (And if you call `Session#resolve_redirects` with a request argument that isn't the `PreparedRequest` corresponding to the response argument, it silently blows up in your face.  This is, I imagine, because this API wasn't originally intended for public use.)

So. I still think it is appropriate to cache the full set of kwargs to `Session#send` on the request (or perhaps the initial response) so that they can inherit to subsequent redirects without further user intervention.  But I am persuaded that I should make both `resolve_redirects` and the new `resolve_one_redirect` take arbitrary kwargs which override the cached kwargs.  And, if Kenneth agrees with you that the caching is inappropriate, I would also be okay with just having the redirect methods look at the session object for defaults, in the same way that `send` does.