I just tested it here and it did not work for me either, I'm not sure when or how it got broken. Looking at the code I noticed it was expecting that setting to end with .aspx but when I tried using an url that ended with .aspx it still did not work.
I fixed it just now by editing the LoginLink.cs to make it use that setting for the return url param in the login link if the setting is not empty and that fixed it. I have pushed this fix to the source code repository so you could get the fix immediately if you can deploy a build of the latest code, otherwise expect a new release within the next few weeks.
Without that setting the normal behavior of the login link is to use the current page url for the return url param so it will redirect back to the current page after login. Redirecting back to the current page is usually the right thing to do especially for ecommerce where a user may need to sign in to proceed with checkout or for other scenarios such as needing to login in order to reply to a forum thread, we usually want to bring the user back to where he was so he can continue with what he was trying to do. Hard coding a specific url to always use is an edge case scenario which is why it was not noticed whenever that got broken.
Hope that helps,