The support for multipart comes in when we begin to talk about interoperability of the scheduling semantics over email. This is where we ran into the problem between Lotus Organizer and Microsoft Outlook. I was the one who reported it.
At one of the IETF meetings we addressed this under the discuss of errata against iMIP, not iCalendar. It was decided there that a change was needed to the iMIP spec.
Please change it in your "Action Items" document to an iMIP related bug. The iCalendar spec interoperates fine without it, but the iMIP spec doesn't.
The fact that the ATTACH property and the ALTREP parameter _can_ specify a CID or MID URI (as specified only in examples) for the URI based value doesn't mandate that an iCalendar implement MUST support multipart MIME entities. Indeed, the MID URI for an ATTACH property could specify an message identifier external to the current message. The standard specifies that the value is either a URI (which could be other URI types than a CID or MID) or an inline binary value. ALTREP is a URI value. Most probably NOT a CID or MID URI but more likely a HTTP URI.
In fact, an iCalendar CUA is very likely to support inlined attachments and HTTP type URIs for alternate representation of text content.
It is a big jump to say that all iCalendar implementations MUST support multipart. In fact an implementation that is using iCalendar for import/export won't be doing this. The point is that many implementations will conform to the RFC2445 just as a content definition.
-- Frank