That is good! I forgot about this case. This is the case where you send out a REQUEST (SEQUENCE=0), then follow it up with a REQUEST (SEQUENCE=1, RECURRENCE-ID=19990726T133000Z) that changes the LOCATION (or some such peripheral property). Now you can't just send one REQUEST reply to the REFRESH. The RECURRENCE-ID values specifies one occurrence that will need a separate REQUEST to specify the different LOCATION property (or whatever).
Now, if this difference was expressable with a REQUEST, then Alex is correct, there are three ways to express this. It would be nice to agree on a common one to simplify interoperability. However, if this could only be expressed with a different method (i.e., ADD), then you can't express this as a single iCalendar object containing two VEVENT definitions. Rather, you need two iCalendar objects in a multipart/related or multipart/mixed container. Hence, if we agree that a common "packaging" is necessary, then it ought to be the multipart approach. Right?
-- Frank