The review for SE-0251: SIMD Additions ran through April 1st.
There was very little formal feedback in the review. SIMD is a relatively niche topic, and this is a relatively rarefied extension to the SIMD APIs, so it's unsurprising that most people didn't feel any need to express an opinion about it, and that's fine. However, as a frequent review manager, I'd like to encourage people who do have an opinion about a proposal to always write at least some formal feedback on it; even something as basic as a "+1" in the review thread provides a much clearer signal than, say, clicking 
on the review post, or only commenting in the thread to try to answer objections raised by other people's reviews.
Feedback was generally positive overall, but each review expressed some reservations about various parts of the proposal. Many of those reservations were addressed within the thread, and the Core Team agrees with those responses. The proposal author agrees that there's no need to special case the swizzles on SIMD3, so those clauses will be struck from the proposal. The principal remaining objection is to the addition of any and all to the global namespace; the Core Team agrees with this addition, but we'd like to explain our reasoning in a bit more detail.
It is a primary goal of Swift to support fluent and expressive libraries. The API design guidelines are explicit that the highest priority in library design is clarity at the point of use. Consistency is only a means to that end, not a goal in itself. In many cases, using a uniform language construct like method calls to spell an API is good design because the consistency contributes to clarity: programmers already understand how method calls work, and method calls combine naturally with features like optional chaining instead of requiring circumlocutions that would harm the overall clarity of the code. But any and all will often be used directly on the result of a binary comparison, making a method call awkward and harder to read, and they will often by used directly as if conditions and rarely in conjunction with optional chaining. In this case, the Core Team feels that a more "DSL-like" approach like that proposed for any and all creates an overall more fluent API.
The Core Team also considered that this use of any and all will likely prevent their future use as keywords. However, claiming these identifiers as keywords would already cause problems with a fair amount of existing code, and it's far from clear that these would be the best choices for keywords in any event.
Accordingly, SE-0251 is accepted with the modification that the special cases for SIMD3 swizzles be struck.
As always, thank you for helping to make Swift a better language.
John McCall
Review Manager