After some discussion, we came to these conclusions:   While the property name of Appointment.participant.type does somewhat imply it is describing the type of participant, the definition and comments, and value set all seem to clearly indicate that it is the participation type that is being represented.   Having two properties, one for participant type (role) and one for participation type, didn't seem necessary, as the participant type for actors typically invovled in appointments can be represented in the referenced resources (e.g, PractitionerRole.code).  Note all reference resources have such a type/role property, but we haven't heard that implementers have a need to distinguish those for resources beyond Practitioner. We aren't sure that changing the participant.type name to participant.role is worth it given the current levels of adoption.   As a result, we are proposing to make no changes, and instead rely on our definition and comments for the participation.type property to communicate the intent of that property.