Malte,
Same behavior.
I really think this is rooted in a change of philosophy regarding what to do with a set of unrecognized credentials.
As Lars explains (see the bugtracker thread), on a production site, it gets really messy when a registered user mistypes or enters an unknown (possibly valid to the user) email when asked to identify himself. The old (pre 5.0) system behavior was to immediately redirect to the new user registration page. Lars says that in _many_ cases, the user continues and registers a new email address. This is not a good thing and I agree that this should be discouraged.
The 5.0 behavior was changed to _not_ redirect to the new user registration page. It is intended to make the user pay attention, and it probably serves that purpose well. In order for a new user to register at this point, he has to click the register link. This is where a problem arises, for two reasons:
- A new user is now required to explicitly click the register link, and IMO the register link is not prominent.
- When the new user follows the register link and completes registration, he is not redirected to the page that initially required authenticated access. He's virtually "lost"
So, the user that I'm trying to lure (maybe a bad word here) painlessly into my site just hit two LARGE roadblocks. OK, maybe one small and one large...
Maybe we can't do much about the explicit "register" click except to make the instructions and UI easier to use - possibly two large square graphics or buttons side-by-side that really make it clear that you can either RE-ENTER existing account credentials, or REGISTER FOR A NEW ACCOUNT. We should require an explicit click to proceed down either of these paths. Make the choices prominent and equal.
No matter how the UI is handled, the return_url _must_ be carried through however many clicks it takes to get authenticated, and the end result of this sequence _must_ be to place the user in the location he initially requested.