Wouldn't letting people log in again after people accidentally logged out be a slightly less annoying solution than "Are you really sure you wanted to click what you just clicked" dialogs? Logging out is a non-destructive activity that can be reverted by logging in again. No data loss.
Honestly asking as an entire generation’s computing experience is built around clicking ‘OK’ to dialogs that they either don’t read or don't understand.

Hi. I'm the user requested this feature. The reason for my request was because: I largely view and edit Wikipedia in desktop view on mobile browsers, since I can use more functionalities in desktop Watchlist/2017 editor/TW. The problem is, my thumb often slip on the logout link when I meant to click contribs. And since I don't remember my randomly generated passwords - I use password managers for that - I have to take some extra minute or two unlocking the manager app and copying password to the mobile browser. It'd really be convenient to have this script as a optional opt-in gadget. Thanks.

Ah, thanks for the comment! Anyone is free to set up such a gadget or user script if they feel like, sure. :)
We do not track random gadget requests in Phabricator tickets, so I expected this to be a request to be implemented in the MediaWiki core software. https://www.mediawiki.org/wiki/Gadget_kitchen/Requests does not look very active, hmm.

Isn't this what we have the mobile website for ? So that the links are big enough that you DONT accidentally click them ? I mean this is the road towards having confirmation dialogs on EVERY action, and then we need preferences because other people DONT want confirmation dialogs etc etc etc...

Requiring confirmation to logout should be available, even if it's just an option you can set in preferences. On a mobile device, it just takes an errant finger tap to log you out, and that happens fairly frequently.

I've got 2FA enabled on my account. If I don't have my token generator with me, it's doubly annoying. Even more so when coupled with T37220

This should be fixed in the skin, not in MediaWiki. Took a guess that the people who have a problem are using Vector (the other skins are semi-unsupported anyway).

It's not a mobile-only problem; I've clicked log out accidentally on desktop using a mouse.

I think there is a reasonable design problem in that Logout is the only user link that actually is (lightly) "destructive" in the set of links where it is located, in multiple skins. All the others will accept a browser back button to restore your previous state (though clicking watchlist will take a while because the watchlist changes this past year or two did not do a favor to the time to load the watchlist), so misclicking on those isn't painful to deal with.

Misclicking on log out is.

Minerva is the only skin today where I see an obvious solution (move logout to where login is, on the left hamburger menu), but even that has potential, once you're logged in and have all your gadgets/scripts loaded, to cause the grief of hitting the wrong link.

I don't necessarily know if there is a good way to fix that without throwing everything out that is standard about our skins. :)

Providing a time-limited undo option, maybe. But it would be way more effort than worth it.

FWIW it is easy to add a confirmation dialog to the logout link from a gadget.

Actually, a confirmation dialog is allready in place on the userLogout page, but it's made unavailable when using the ordinary logout links in Vector or Minerva. Whether that's intentional or not I don't know.

As the use of mobile gadgets are increasing, I think at least an easy way to choose having a confirmation dialog on logout should be standard. Mobile gadgets are frequently used also for contributions to our different projects, but Minerva is not suitable for much more than reading.

Of course, one can make scripts for this. Temporarily, I actually found that a quick workaround was changing the name on the logout link's id (and for Minerva a class could be removed), but such changes could in time lead to other bugs. Another way is to produce new confirmation dialogs locally, to cover up for the one which is just made unavailable, but that should just be a temporary solution.