> Because otherwise I wouldn't be able to get it back. But if I have some kind of temporary hiding feature, I can easily use that as soon as I notice that the operation hasn't immediately completed.

A toast notification doesn't preclude being able to recover state. Email applications still have an Outbox and Sent folder. A UI that allows you to place orders can still have a Pending Orders list.

> (And again, the common case should be that it completes immediately.)

In the real world, not all operations initiated by the user can complete immediately.

> And if something isn't supposed to be instantaneous, I hold that the interface shouldn't be modal anyway.

Why not? The two things are orthagonal. Collecting information about the user's intent and acting on that intent can often have differing workflow implications and timings.

Blanket rules are almost always useless in UX. Say you have an interface made to place an order. You collect a bunch of details about the order modally. The user confirms and submits the order. But it'll take a minute or two for a vendor to confirm it. What should happen next is COMPLETELY dependent on the context of the application. If this site is where the user is ordering dinner, it makes complete sense to leave the user in a modal state until confirmation occurs, because it's unlikely they're going to be placing another order for dinner immediately after, unless the first order fails. If this site is made for a procurement professional placing 20-30 orders one after another, it makes complete sense to background the confirmation and report status non-modally.