Hi,
Yes, the semantics of the case with a connector from a relay port to an internal behavior port, is the same as if the relay port was an external behavior port.
One use of this special case of connector is when you have a super-class capsule, where you have only relay ports. In the legacy tooling there is no way to redefine a relay port into an external behavior port, so then you have to add and internal behavior port and have this delegation connector which connects the relay to an internal behavior port to be able to connect it to the behavior of the current capsule.
We had some discussions a long time ago whether the new code-generator/run-time could support the redefinition of a relay port into a external behavior port in the subclass capsule (which is also indicated in
bug 507552 and the section about which properties for a port that shall be possible to redefine). And the result of this was that the assumption was the it should be possible to do such a redefinition (something that the legacy tooling does not support). And thus this special case of connector is probably reduced. But since it is supported in the legacy tooling due to this redefinition limitation, I guess this connector case also needs to be supported.
So I guess, you really should make sure that both the redefinition of a relay port into an external behavior port actually works in the code-generator and run-time, as well as the support for the connector from a relay port to an internal behavior port. If the former does not work (and thus we have the same limit as in the legacy tooling), the latter case with the connector definitively needs to be supported. If the former indeed works, then the latter case with the connector probably still needs to be supported for legacy reasons.
/Peter Cigéhn