What you wrote is correct for the malled transaction. The edge-case concern is if you quickly build a second transaction using unconfirmed change from the first transaction (that got malled).
Obviously the coffee shop will only accept transactions whose inputs are real, that is, in the block chain. If they aren't in the block chain, in general it can't be sure those input transactions were even submitted to the network.
A problem only arises if the coffee shop wants to let the customer use the change from a prior transaction
at the same coffee shop. Which is a bit of a bodge, and unnecessary. The bodge doesn't help in the case where the customer buys coffee from one shop and then tries to use the change to buy a paper from the newsagents next door. To cope with the two-shops case, the customer's wallet needs to make sure it never tries to spend unconfirmed transaction outputs; and that also works in the one-shop case. There's no good reason to treat unconfirmed change differently to other unconfirmed transaction outputs.
It seems like a total non-issue to me, even if malleability isn't fixed.