True, Because enum cases would now do double-duty: when used without arguments they refer to their family (eg: .baz) and when used with arguments, they more-or-less refer to an instance (eg: baz(123.0) ).
If we make .a() an optional, how big a problem is this? To provide the same functionality with Swift at present requires a lot of code (eg: a second enum, custom getter, then using switch statements and "if let case" nonsense).
I think this might be a problem in theory, but a non-issue in practice. Even now, an enum with a payload in Swift is already basically a type. Whether we use existing Swift enums, or the paradigm I like, the programmer needs to know about the specific case, and the type(s) of its payload.
I should also point out, that these problems are those that occur using my hacky enum-like structs in Swift, as it exists now. Even so, I find them minor — if they were built right into Swift, the compiler could, for example, type check the second example live. Maybe even the first example could be solved with some sort of magic.