Well, yes, and no, and yes, and no.
You are right, with the corrections you made, that my version would be misinterpretable as satisfying the condition on iOS 12.
However, according to the current proposal, every multi-clause unavailability check will evaluate to false, and this is going to be an error, not a mere warning about unreachable code. So, your multi-clause counter-example isn't something I was expecting to be valid anyway.
With a single #unavailable clause, it's a bit less clear cut, because I think it's natural to assume that listing the platforms to specific cases (and no "default" case) would imply that the code will execute only on those platforms. After all, the reason why we do have a default case in an #available check is that omitting it would tend to suggest that its code would execute only on the explicitly listed platforms.
However, on reflection I admit that it's a fairly weak argument, so I withdraw the proposed syntax amendment.
However, I'm going to go a bit further and say that it's pretty clear from (for example) this thread, that when trying to describe the '*' in an #unavailable condition, multiple people have got it wrong — even, I believe, you. (false was the correct answer.)
The only viable way, I am convinced, for a reasonable person to understand what an #unavailable condition means is to drop the 'un', work out what the #available condition means, then negate the answer.
For that reason, I think there are only two reasonable ways to proceed:
— Spell the unavailability check !#available. The question of whether it's stylistically worse is far outweighed by its clarity of meaning.
— Drop this proposal, and fall back to if #available(…) { } else { … }. It's a little ugly, but it's a small price to pay to avoid the confusion that #unavailable seems likely to produce.