@typesanitizer Reading back over your comment now, I can't identify any part of the critique that isn't more generally applicable to having variadic parameters in non-primary positions. E.g., with regards to assertArgs you say:
But an alternate version of the API could be written (without SE-0284) as:
try assertArgs(["swift", "-foo", "-bar"], parseTo: .interactive, leaving: "-foo", "-bar")
The same goes for the addSubviews example. Perhaps the "after" versions are not the best examples of APIs that could be helped with this proposal, but AFAICT your comment would be more applicable as an argument against adopting those specific APIs (and could perhaps apply to a more general pattern of APIs which might use SE-0284).
IMO, this is unfeasible as a general policy. We certainly can't force proposal authors to respond to every concern, nor does it seem reasonable to me to reject an otherwise-sound proposal on the grounds that an author did not respond to some comment. It's the job of the Core Team to synthesize all the feedback a review generates and make a decision, and they are capable of doing that whether or not every comment has a response.
Of course, if someone raises a concern in a review thread, by not responding the proposal author is foregoing their last opportunity to convince the Core Team that the concern need not be (or already is) addressed by the proposal—but ultimately, that's their prerogative.
ETA: We do currently have this note as part of the Swift Evolution Process document:
To avoid delays, it is important that the proposal authors be available to answer questions, address feedback, and clarify their intent during the review period.
This sort of 'soft' expectation is about as strict as I'd like things to be, officially.