In my opinion, the best alternative would be to announce these pitches as soon as they were ready, and to go through the usual evolution process for the community to discuss these features, without any surprise reveals at the WWDC keynote. If these weren't ready to be merged, then it would make no sense to build any "Swift-only" frameworks on top of these features. Otherwise the statement "SwiftUI is a pure Swift framework" would not be true, it is at the moment "a framework that uses Apple's flavour of Swift".
Now we see that either way these features will ship by September 2019, which is we can safely bet is the release date for Swift 5.1. Which, by the way, is dictated solely by the iPhone and iOS 13 release schedule. Let's hypothetically consider a scenario that due to a pushback from the community, the proposals aren't accepted by that time. This means that we'll have a flavour of Swift released with Xcode 11 with some features of that used in SwiftUI for iOS 13. It's highly like that SwiftUI API for iOS 13 will be more or less frozen until iOS 14, which means that those language features will be frozen too.
I totally understand the opinion that SwiftUI has to ship ASAP in whatever state it is. Unfortunately, Swift's ecosystem is already massively fragmented on other platforms. Consider a fresh post in a thread about server-side Swift:
Please consider that if Swift features required for SwiftUI are going to be shipped in September 2019 without going through a proper evolution process, with what would basically amount to a language fork, things would only get worse for other platforms. I competely support replacing UIKit and AppKit with something more modern, but this should not come at the expense of the ecosystem and the community as a whole, and cause even more fragmentation than we have now.