I'm a big proponent of not showing messages blocking users from doing what they intended to do. The UX solution with confirmation popups came from the Stone Age of computer UX practices. It originates from a correct assumption that if we have a critical resource, we should not let users damage it by an accident. However, an accidnet is called that way because it happens rarely. This means in the majority of cases that confirmation is just a waste of a click.

However, we do have to protect users from accidents. So the right way of doing this is to save current state in undo stack, proceed with the operation, but then let user cancel or undo it. I would consider this solution more like a guideline, rather than a rule, but I'm sure it can be applied to many cases.

For instance, in case of shutdown Apple saves current state for all your applications. When you power up again you come back to your work as if you haven't shut it down.

If an operation may destroy irreversibly a critical resource (for instance, delete something in 3d party application via API) then schedule the action to start in nearest future, say in 60 seconds, but let user cancel it, if they like.

That said, I think in majority of the cases these kinds of confirmations are not needed.

I'm a big proponent of not showing messages blocking users from doing what they intended to do. The UX solution with confirmation popups came from the Stone Age of computer UX practices. It originates from a correct assumption that if we have a critical resource, we should not let users damage it by an accident. However, an accident is called that way because it happens rarely. This means in the majority of cases that confirmation is just a waste of a click.

However, we do have to protect users from accidents. So the right way of doing this is to save current state in undo stack, proceed with the operation, but then let user cancel or undo it. I would consider this solution more like a guideline, rather than a rule, but I'm sure it can be applied to many cases.

For instance, in case of shutdown Apple saves current state for all your applications. When you power up again you come back to your work as if you haven't shut it down.

If an operation may destroy irreversibly a critical resource (for instance, delete something in 3d party application via API) then schedule the action to start in nearest future, say in 60 seconds, but let user cancel it, if they like.

That said, I think in majority of the cases these kinds of confirmations are not needed.