Clarification on order of operations when executeCommand results in multiple applyEdits

This is a question related to #2002
Two questions, really:

1. Is there a server that would ever produce more than a single applyEdit on executeCommand?
2. What is the exact order of operations?

To elaborate on the second, my client does this:

1. Send executeCommand request
2. Receive applyEdit
3. Respond to applyEdit
4. Receive executeCommand response
5. Assert that there was at most one applyEdit
6. Actually apply the edit and send change notifications.

I could aggregate more applyEdits and apply them all at once, i.e.

1. Send executeCommand request
2. Receive applyEdit
3. Respond to applyEdit
4. Receive another applyEdit
5. Respond to that
6. Receive executeCommand response
7. Actually apply the edits and send change notifications.

But I'm assuming that the intention was:

1. Send executeCommand request
2. Receive applyEdit
3. Apply it.
4. Send change notification.
5. Respond to applyEdit
6. Repeat 2, 3, 4, 5
7. Receive executeCommand response

Only, there I have not clue what should come first - the change notification or the applyEdit response.
Once again, having a server to test against would be crucial in order for me to implement this kind of thing.
All the servers I've come across either produced 1 or 0 applyEdits on executeCommand.

Read issue #2002 and the executeCommand/applyEdit protocol definitions first. Resolve whether multiple applyEdit requests are allowed and document the required sequencing of edit application, change notifications, and responses, including a reproducible server case if available.