The name isFalse originates from the different thread mentioned above, where we also assume that Bool is kind of an enum with two cases called true and false:
Since I personally prefer writing boolean == false rather than !boolean, isFalse is automatically my preferred name for such property than toggled, but the name can be debated in another thread if we're truly going to re-evaluate the addition of a Bool property that returns the negated value.
My only point is that a Swift developer should not create his own extension for such a convenient as he discovers the key-path functionality added by this proposal and otherwise the lack of being able to invert the result returned from a function with a predicate.
We also should ask ourselves, what new algorithms can we express with a pitched extension, so in case of isFalse, previously it would have been only 'pure sugar' or third way expressing the same thing, but with this proposal it will actually allow inverting the result of functions with a predicate, a use case that has not existed by now.