Change:
send the contents of push messages as they are sent by application servers. <del> Each push message is pushed in response to a synthesized GET request. The GET request is made to the push message resource that was created by the push service when the application server requested message delivery.  The response body is the entity body from the most recent request sent to the push resource. </del> <ins> Each push message is pushed as the response to a synthesized GET request in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the application server requested message delivery.  The response headers SHOULD provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push" and a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by the application server. A user agent can also request the contents of the push message subscription resource immediately by including a RFC7240 with a "wait" parameter set to "0".  In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered. A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available.  This could be because push messages have expired. 6.1. </ins> <del> In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered.  In addition, the push service SHOULD return link references to the push and receipt subscribe resources. </del> <ins> There are minor differences between receiving push messages for a subscription and a subscripion set. A user agent requests the delivery of new push messages for a collection of push message subscriptions by making a GET request to a push message subscription set resource.  The push service does not respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. Each push message is pushed as the response to a synthesized GET request sent in a PUSH_PROMISE.  This GET request is made to the push message resource that was created by the push service when the application server requested message delivery.  The synthetic request MUST provide a URI for the push resource corresponding to the push message subscription in a link relation of type "urn:ietf:params:push".  This enables the user agent to differentiate the source of the message.  The response headers SHOULD provide a URI for the receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt".  The response body is the entity body from the most recent request sent to the push resource by an application server. </ins> A user agent can request the contents of the push message <del> subscription resource immediately by including a RFC7240 with a "wait" parameter set to "0". </del> <ins> subscription set resource immediately by including a RFC7240 with a "wait" parameter set to "0".  In response to this request, the push service MUST generate a server push for all push messages that have not yet been delivered. </ins> A 204 (No Content) status code with no associated server pushes indicates that no messages are presently available.  This could be because push messages have expired. <del> 6.1. </del> <ins> 6.2. </ins> To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message

Discussion:
These are the initial and incomplete changes related to the subscription set feature. One remaining gap is how a push service correlates two different subscriptions. See the for the related thread.
Overall I like how this looks. The PENDING section on how a server might know to attach new subscription requests to an existing subscription set could be resolved by requiring a client upon connecting to immediately request delivery of a notification set before asking for new subscriptions. This way the connection handler can associate the subscription set with the connection, and a server may then associate new subscriptions with the outstanding subscription set request. This could also provide a client with a way to manage 'groups' of subscription sets, since it could assume that the last subscription set it asked for is what new subscriptions on that connection will be attached to. This could be useful for the IoT use-cases where a client might want to have some input on which subscriptions are grouped together.
I was thinking even simpler for correlation: include link relation to a subscription set in the request. That allows clients to share a connection without risking the server creating a set that they can't use. For instance, applications using URL on windows could use the same HTTP/2 connection to a server (though I don't think that they do, the protocol permits, even encourages it). However, they might independently want to use push. Sharing a subscription set is not entirely practical in this case. Good point. In earlier discussions, one proposal was to pass the first subscription resource that was created (as parent) with subsequent subscription requests (children) to provide that common link between the user agent and push service. This allowed the user agent to make the decision to aggregate or not. If it did not pass a parent subscription, then the push service could not aggregate the separate subscriptions. My thought was to avoid 'special' properties on the first subscription. The subscription set ensures a clean separation between operations on aggregated and individual subscriptions. For example, the user agent can continue to GET (or poll) and DELETE individual subscriptions - including the first one. To enable the current proposal where the push service makes the decision to aggregate, there must be some form of client authentication/identification included with the subscription request in order for a push service to correlate the subscriptions.

Darshak noted this in a previous message: I’m not sure how a PS can force a UA to aggregate (unless the PS somehow identifies the client based on authentication/cookie/something-else). I may be taking it out of context as "something-else", but Benjamin also commented: I'm associating one h2 connection as being one UA