Changes have been made in Git (develop):

commit d94d32963740fda3026fea230c2854a26dc35255
Author: Jan Schneider <jan@horde.org>
Date:   Tue Oct 16 18:46:24 2012 +0200

     [jan] Use more compatible message format for iTip notifications 
(Bug #9854).

  kronolith/docs/CHANGES      |    1 +
  kronolith/lib/Kronolith.php |   13 +++++++++++--
  kronolith/package.xml       |    2 ++
  3 files changed, 14 insertions(+), 2 deletions(-)

http://git.horde.org/horde-git/-/commit/d94d32963740fda3026fea230c2854a26dc35255

Changes have been made in Git (master):

commit d94d32963740fda3026fea230c2854a26dc35255
Author: Jan Schneider <jan@horde.org>
Date:   Tue Oct 16 18:46:24 2012 +0200

     [jan] Use more compatible message format for iTip notifications 
(Bug #9854).

  kronolith/docs/CHANGES      |    1 +
  kronolith/lib/Kronolith.php |   13 +++++++++++--
  kronolith/package.xml       |    2 ++
  3 files changed, 14 insertions(+), 2 deletions(-)

http://git.horde.org/horde-git/-/commit/d94d32963740fda3026fea230c2854a26dc35255

IMHO, the google method is the best:

0 [multipart/mixed] [-]
    1 [multipart/alternative] [-]
      1.1 [text/plain]
      1.2 [text/html]
      1.3 [text/calendar]
    2 invite.ics [application/ics]

Ben promised to do some cross-client tests to find out which of those 
structures is most portable.

And finally iCal (which looks most broken of all):

0 [multipart/alternative] [-]
   1 [text/plain; charset=iso-8859-1]
   2 [multipart/mixed] [-]
     2.1 [text/html; charset=iso-8859-1]
     2.2 iCal-20111102-100028.ics [text/calendar]
     2.3 [text/html; charset=iso-8859-1]

Outlook:

1 [text/calendar; charset=utf-8]

Awesome, there aren't any two clients that do the same :) can somebody 
send me Outlook and iCal invites?

Lightning:

0 [multipart/mixed] [-]
   1 [multipart/alternative] [-]
     1.1 [text/plain; charset=utf-8]
     1.2 [text/calendar; charset=utf-8]
   2 invite.ics [application/ics]

And in Outlook-compatibility-mode:

1 [text/calendar; charset=utf-8]

Google:

0 [multipart/mixed] [-]
   1 [multipart/alternative] [-]
     1.1 [text/plain; charset=windows-1252]
     1.2 [text/html; charset=windows-1252]
     1.3 [text/calendar; charset=utf-8]
   2 invite.ics [application/ics]

This is what iCloud uses:

0 [multipart/mixed] [-]
   1 [multipart/alternative] [-]
     1.1 [text/plain; charset=utf-8]
     1.2 [text/html; charset=utf-8]
   2 iCal-20111013-134128.ics [text/calendar]

I've just received an iTip response the other from what identified 
itself as "Mozilla Calendar", and that did you use this structure 
(leaving out the multipart/related part with the html version). A bit 
awkward though was the fact that it used text/calendar for the 
iCalendar part inside the multipart/alternative part, but 
application/ics inside the multipart/mixed part.

What structure do outlook and google calendar invites use? Do those 
programs, and programs like thunderbird, handle Michael's proposed 
structure gracefully?

This is correct.
I don't agree with this statement.  What if I receive an event 
notification and want to import it into a calendar not associated with 
my MUA program.  For example, I want to import to a shared calendar on 
Google Calendar.  It would be nice to be able to download the .ics 
file to upload to Google Calendar.

Since they are the most rich part of the multipart/alternative 
message, they should show up, if the MUA supports it, right? If not, 
the user can't make much use of it anyway.

Other than the fact that the iCalendar file won't show up as an attachment?

If it's just the wording, we can replace it. Or is this structure 
causing real-world problems?

Another example of the multipart/alternative problem.  We send out 
notification messages that look like this:

multipart/alternative
   text/plain
   multipart/related
     text/html
     image/png
   text/calendar

The problem comes if a MUA does not know how to handle text/calendar.   
Both the plain and html contains language about an attached iCalendar 
file.  But as discussed in other bugs, text/calendar, if it can't be 
displayed, must NOT be shown as an attachment.  Multipart/alternative 
is only designed to provide different viewable representations, it is 
not intended to be a container for downloadable attachments.

The proper way of doing this would be as follows:

multipart/alternative
   multipart/mixed
     multipart/alternative
       text/plain
       multipart/related
         text/html
       image/png
     text/calendar
   text/calendar

Yes - text/calendar is repeated twice.  However, this is expected (and 
necessary) behavior.

A rarely used MIME type (message/external-body - RFC 1873) was 
designed to solve such issues - it allows data to be defined in one 
MIME part, and the data to be duplicated in other body parts by 
reference to the first MIME part.  But I'm not sure how many MUAs 
support this.