Hi Piers,

I agree this is something that I am sure annoys administrators the world over.

The change however is very intentional and despite the inconvenience it causes we would not change how it operates by default.
The reason it is done this way is to prevent any chance XSS exploits via the return to user action when a user has used login as to assume the guise of another user.
As an example of how this could be done:

• Student discovers XSS attack vector. 
• Writes some crafty JS that does some nasty that would open a window with the "return to admin user" link.
• Files a support ticket with helpdesk, stating a problem on the given page.
• Unsuspecting admin uses loginas to see what the student sees.
• XSS code opens new window to complete the "return to admin" action.
• Original window with the XSS code now has admin access to the site.
• Users script proceeds to complete tasks as the admin, making themselves admin, removing other admins, firing off spam etc.

Such an exploit is achievable if the user is able to return to the original role if they have used login and are not prompted to authenticate.

Now that the student discovers an XSS attack vector sounds like they have already discovered an exploit, and they may have.
However the difference with this attack is that often the only place someone can get malicious JS to execute is somewhere only they themselves can see - the reason for this is that those areas are not often closed off as it allows for custom functionality and the user is only able to attack themselves.
A good example of this is when editing the user profile, turn the editor to HTML mode and set your description to:

<div onclick="alert('Hello!');">Click me</div>

Now change your editor back to the normal mode and click on the words "Click me".
You get an alert, which is expected, when you save the JS is stripped and everything is safe, but until you save the editor (both TinyMCE and Atto) process the JS as it may be permitted. It is when it is saved that it is stripped.
This typically isn't a problem as the only user who can be exploited is the user who is editing their profile.
However a malicious user with a little more smarts that I will not disclose here could create content that would allow the above example to happen.

In terms of solutions there is a long running improvement conversation upstream on Moodle about how to solve this MDL-24120.
The reality is that for the sake of a single password some people are willing to take the security risk.
They have talked in the past about adding a setting so that this can be disabled, or automating submit of the login form if the password has been saved.
Really they can not come to an agreement because the security risks are real and the benefit is marginal - an additional entry of credentials for a safer installation.

Given this information would you want some way to disable the login requirement when returning to your account?
We can't turn it off by default, however potentially if there is enough of an argument and it proved popular we could look for a solution where Moodle has failed to agree.
If so a little information on your use case and whether you would want a setting or something else would be appreciated.
The same goes for everyone else who is interested.

Cheers
Sam