As I said in the pitch thread I'm generally in favor of this proposal. However, as I mentioned there (with no reply), I am not entirely satisfied with the one year cycle for removing API that has migrated to the standard library.
I think we should seriously consider a separate stream of releases that always requires the latest released version of Swift (or later) and drops any symbols that have moved to the standard library as of that Swift release. This would provide a better alternative for users who do want to update quickly to the latest version of Swift. It would also ensure more immediate usage of the library implementations because users of the "edge" release would not need to modify code to switch to the library's implementation. In order to avoid confusion this version of the preview could have a different module name (i.e. SwiftPreviewEdge or something like that).
Supporting two streams of preview package releases is obviously more work for the package authors. However, I can speak from experience in saying that with appropriate planning it isn't terribly burdensome to support multiple build products from the same Swift sources.
One advantage having two streams of releases from the same source is that the Swift project contributors will gain experience in doing exactly that. It is possible this could motivate language features that would improve Swift's ability to fulfill this kind of requirement. (In some cases more boilerplate than is ideal)
If the core team decides it doesn't want to support two streams of release I think the one year timeline for staging features out of the preview package is much too long. When a new version of Swift is released it should be accompanied by a release of the preview package that does not include any symbols shipping in the standard library. This will ease adoption for those of who prefer to live on the bleeding edge. Users with slower update cycles are less likely to want to use the preview package anyway.