I can see how you see it this way Jon, but there is really only one bug here: if let implies an optional unwrap. We actually discussed forcing people to write:
if let x = foo() {
as:
if let x? = foo() {
which would have made the language far more consistent w.r.t. pattern matching, and would have completely eliminated the need for the if case construct. However, we were in the the Swift ~1.1/1.2 timeframe and we decided that this would unnecessarily uglify the common case and force people to learn about pattern matching early. As a consequence of that (IMO in retrospect, "short sighted") decision we have a lot of complexity around let and var that we didn't need to have.
However, that history doesn't imply that we should continue the antipattern. The proposal here doesn't have similar justification, and the failure to compose isn't warranted. While it was costly, we did make if let compose, we were just forced to spell it if case let x? = instead of if let x? = due to the compatibility issues.
I respect your opinion here, but I find it hard to feel as strongly as you do about this given we have almost zero usage experience with this new sugar. We shouldn't rush to sugar things we don't understand - language features are the MOST DIFFICULT thing in the Swift ecosystem to back down from, but are comparatively easy to add later if they are missing.
This is a typical issue with new language features - we all project our expectations onto them and draw conclusions based on our experience in other systems or (sometimes) when porting our code to early betas. However, without a reasonable range of experience using it (including in brand new code bases!) we can fall into traps of carrying old patterns into the new world even when there is a better way to solve the problem.
I care far more about Swift being a great language in 2 years than I do about micro-optimizing the next 3 months.
-Chris