Hmm... well, authentication and authorization are always hard for me to keep track of. Lets call it identification and authorization.
The system has to support several possible techniques. For instance, some portions of the website are served up as static files directly, so Apache authorization needs to be used (require valid-user or something), or some Apache module that gives a richer set of controls. But web applications often have shifting and eclectic permissions, so I don't want to use Apache to control those permissions (or at least not require that).
One reason I don't like 307 is because (a) programs that already expect REMOTE_USER usually respond with 401 (and I want to provide REMOTE_USER), and (b) the details of the redirect are best understood by Apache, not the individual applications. But if I have to use a redirect, I'll probably put the redirect location in an environmental variable, to at least keep the configuration centralized.
The POST thing is clearly a problem. It's one of many usability issues that POST proponents ignore. Obviously a POST-understanding redirector would be nice.
One of the advantages of a signed cookie is that identification happens once, and need not be efficient, and only the cookie verification happens on subsequent requests (which ought to be quite fast). But I'd like this all in C (which is what tkt offers) instead of mod_python, in part because mod_python is challenging to maintain in its own right, and not Apache 1.3 compatible.