I come a bit late into this discussion, so I do not have all the background on past dicussions that you folks have. Nevertheless, that won't stop me from voicing my opinions:
(1) In ObjecTime/ROOM, there was a clear distinction between the "concurrency level", which incorporated capsules, protocols, and state machines, and a "passive data level", which covered passive classes and their behaviors. The latter was used for capturing message data and local capsule variables. However, it was still all one language, with two clear domains. I mention this not for nostalgic reasons, but because this provided a useful conceptual and methodological framework that helped people decide where and when to use which parts of the language. From what I recall from user feedback, this crisp partitioning worked out well. As things currently stand, the UML-RT/UML split does not bring out this distinction clearly enough, nor does it provide the kind of methodological guidance that existed in ObjecTime/ROOM. I suspect that people, especially beginners, will be confused as to which they should choose (UML-RT or UML) at a given point. My suggestion (which may not be appreciated much by legacy RSA RTE users) is to make the concurrent/passive split more explicit. It may come down to simply renaming the menu items (e.g., instead of the terms "UML-RT" and "UML" use terms such as, respectively, "Concurrency" and "Passive" - or something similar). This also reenforces the view that this is one language, not two that have been duct-taped together arbitrarily.
(2) Remember that we may want to support passive class state machines, which means that these state machine diagrams will have to be made available for passive classes.
(3) Similarly, I think we must allow protocol state machines (standard UML ones are quite sufficient) to be associated with protocols.
Cheers... Bran