Hi,
This was a good question! I had to play around a bit a see how the legacy tooling behaves, including going back one older generation to RoseRT. Before going into the details how it looks like, I need to point out an important difference between RSARTE and RoseRT and its meta-models. Especially this question about where the primary context for editing a port and its properties are made, i.e. on the "outside" or on the "inside". RoseRT is based on UML 1.x and ports on capsule parts is handled differently, and so is the terminology. In RoseRT you have capsule roles on which you have port roles. The capsule role is typed by the capsule and the port roles are "typed" by, i.e. references, the ports on the corresponding capsule. So what you see on the outside are not the ports themselves, but port roles, and the properties presented in the properties dialog are basically a read-only subset of the properties of the port. This is rather different in RSARTE (and Papyrus-RT) based on UML 2.x where you see the actual ports directly on the outside on the capsule part. So yes, in RoseRT you *have* to go inside to to see, and edit, all properties of a port. But in RSARTE/Papyrus-RT you directly see all the properties, and can edit them, on the outside as well. So you don't have to go inside in the corresponding way as you had to in RoseRT. Just clarifying a (rather fundamental) conceptual difference between those two different generations of legacy tooling.
So, I made a similar model as what Christian made, but also extended it a bit to show a redefinition case as well. We have three inheritance chains Capsule1 <- Capsule2 <- Capsule3 and CapsuleA <- CapuleB <- CapsuleC. In CapsuleA have port "protocol1", CapsuleB adds port "protocol1_2" and CapsuleC adds port "protocol1_3" and redefines port protocol1.
As can be seen, the legacy tooling in RSARTE consistently visualizes the ports on the outside the same as on the inside.