4. Frontend registration with verification self, verification while logged in as different user

This shouldn't pass. That is exactly why the current code is designed to stop that you are removing. The only thing that we need to allow is the admin activation to be allowed through.

The fix you need is to apply f7754e7 then 34c33dc

What makes you say that it shouldn't pass?
As far as I am concerned that sounds very stupid. I couldn't care less who happens to be logged in. It is completely irrelevent. Why force to logout?

Or start any of the other browsers and enter the link there, and it succeeds!!!!!!

Why should another user be able to confirm the account of another? It shouldn't be possible. We want to make as sure as we can that the user who created the account is the one who is actually activating it. The likelihood of a user wanting two accounts is low in comparison. Hence why we've had this check since 1.5 days!

It is not another user that is confirming the email!. You can't be logged in to verify an email, complete nonsense for both self and admin!

And again, logout or start different browser and you'll succeed! What kind of protection/security is that?????

Why should it be nonsense that an admin is logged in when he goes to verify a user?

Also you stated as one as your use case above 4. Frontend registration with verification self, verification while logged in as different user and that test should fail because as you said it is stupid that a user can be logged in and verify another user

Giving up. This was what was requested. As an exception I created this for J2.5. Couldn't care less whether it gets implemented! J2.5 is dead for me a long time ago!

Had a similar discussion about this on J3 when reverting. Appearantly we have a different opinion.
No interest to continue discussion. No intention to waste anymore time!