Note: this capability can be related to the capability to create multiple logical connections in a single call and how communications can be optimized (both by a connection manager and by an engineering tool)

Each capability introduced increases system complexity (ET, CM). I would only suggest doing this, if there is a significant benefit in doing so.
Multiple connections sharing a single NetworkMessage, translates to multiple ConnectionEndpoints referencing Readers and/or Writers that are part of the same Reader/WriterGroup.

EstablishConnections() will create these references without requiring specific knowledge of this use-case. Thus I believe, that there is no difference in implementation and testing effort.
In fact, distinguishing this use-case, will require the target to validate the input arguments to EstablishConnections() and issue an error if it detects this use-case, which would lead to higher implementation, testing, and conformance-testing effort on the device side.
In addition, ETs have to be aware of this capability (and maybe also CMs, if they possess the ability to generate PubSubConfiguration).

Discussed 2022-02-08:
Agree to add capability to indicate that connections are able to share network message (optional capability).
Some further "ToDos" are needed:

• Research adding error code to return if not supported
• Research, and add if needed, an indication of the max network message the AC would support (should not assume a 1500 byte packet will be acceptable in all cases)
• Some additional clarifications are likely needed to handle cases such as adding a connection to the network message when connections are already enabled and producing data (David took action item for this)

Note I: not supporting this capability includes multiple connections referencing the same DSW/DSR pair. ACs not supporting this capability will be forced to use 1 NetworkMessage for each Subscriber in a one-to-many use-case instead of 1 Multicast message.
Note II: ACs not supporting this capability will also be forced to use multiple NetworkMessages to send data to a single communication partner if not making use of Sub-FunctionalEntities (e.g.: 5 FEs under 1 AC, will require 5 CEPs, each referencing OutputData of their respective FE (its not possible for a CEP to reference data of another FE, unless its a Sub-FE))

The following ToDos are needed as well:

1) ACs that support the capability shall verify that during connection establishment (in one or multiple calls, with 1 or multiple connections) or upon processing the EnableCommunicationCmd, it cannot happen that NetworkMessages that use the periodic-fixed layout change in size. Suitable StatusCodes must be triggered in such cases and configuration of these scenarios rejected.

2) ACs that do not support the capability, shall detect the above mentioned use-cases (a Client attempting to configure NetworkMessage sharing) and return a Bad_NotSupported StatusCode. The specification shall list all conditions under which this StatusCode will be returned.

3) Part 14 enables configuration of the MaxNetworkMessageSize in a WriterGroup. Together with the transport mapping, this translates to a max. size of the frame on the wire.
If the intention is for a configuration tool to set the max. size of a frame to be sent by the AC, then no additional property is needed. The ET knows the transport mapping and may calculate MaxFrameSize - ProtocolOverhead to configure MaxNetworkMessageSize.

If the intention is for an AC to advertise the max frame size its networking hardware supports, then an addition to (most likely) the BNM is needed.

Proposal for capability name: "SupportsLogicalConnectionNetworkMessageSharing" and analogously we may introduce in the future "SupportsLogicalConnectionSubscriptionSharing" for C/S.

some notes on raised issues:
periodic-Fixed by definition in part14/profile has a fixed size and once it is created, it can not be changed, without taking it down first. so adding something can not change the size (packet had to have it in it when it was defined) - so no update for 1)

2) I think it is only one condition in this case.

I question if this capability is an FLC capability or if should be an OPC UA (part 14) capability. The more I think about this it is PubSub specific and has much more to do with what capabilities the PubSub implementation supports. The engineering tools have to be able to handle the functionality supported in the Controller with regards to PubSub

Decided in the CD/IM call on 12-April:

• Add a MaxDataSetWritersPerGroup capability to the PubSubCapabilitiesType in Part 14. (won’t be in time for RC3, but the hope is that a new Part 14 would follow shortly thereafter). I suppose we need a Mantis issue for this.
• Add a CU to the controller profile to require that the PubSubCapabilities be exposed
• As I had discussed with Matthias previously, I see the need to also have a capability for the MaxNetworkMessage size that a device can advertise. I can’t remember now whether a Mantis issue was entered for this

Changes in related issues - results in no change required in our spec