"Bundled vs. Unbundled" commands were discussed in order to distinguish which commands were likely to be sent alone. This does not mean that unbundled commands are required to be sent alone. It is a recognition that certain operations may need to be done outside of the connection establishment process. A ConnectionManager would typically use all commands within one call, if a breakup in several calls is not needed; e.g. when only a small amount of config data is used.

Some commands (the unbundled ones) would need to be sent in specific use cases as needed by the AC. Examples include:
ReserveCommunicationIds when multicast connections are being established
SetConfigurationDataCmd when the configuration is too large to fit in one packet

The bundled commands would include:

CreateConnectionEndpointCmd, EstablishControlCmd, SetConfigureDataCmd, ReassignControlCmd, SetCommunicationConfigurationCmd.
the AC the require bundled commands would only accept this group of commands as a bundle, the bundle does not require all command be included, but any omitted command can not be sent in a separate command. i.e. a Connectionmanager might only include CreateConnectionEndpointCmd, SetCommunicationConfigurationCmd. if the other commands are not needed, but what would not be allowed is a Command of CreateConnectionEndpointCmd, and a separate command of SetCommunicationConfigurationCmd.

In an AC that requires bundled commands, it would be recommended that all commands be bundled, but this AC would still be able to handle the VerifyAsset, VerifyFunctionlEntity, ReserveCommunicationIds outside of a bundle.

The status of EnableCommunication would still need to be discussed.

General comment: A single call will be easier to implement than the support of multiple calls on a target device, e.g. in a single call, the sequence of commands is implemented by the target device, whereas if multiple calls are issued by a CM, the target device must verify the correct sequence. Also supporting multiple calls may require storing state information between calls. I recognize that its less implementation and test effort to support "only" single calls.

Yet, the slideset states: "Devices (including controller) that do not require multiple calls do not need to support multiple calls​"

It is not the device that requires multiple calls, it is the workflow(s) that its being used in, that may require multiple calls. If the support of multiple calls is optional, such devices will not be able to be used in certain workflows.
E.g.: A device that supports only 1 single call will not support the possibility to enable connections in a separate call after their establishment.
Also, 2 devices that support only a single call cannot be configured to exchange messages using the 3-step process (which requires min 2 calls on one of the communication partners), i.e. connections between 2 such devices cannot be configured by > 1CM.

The question for me is: Does the reduction of implementation and test effort by omitting support for multiple calls, warrant the limitation of use-cases/workflows such devices can be used in and does it warrant the additional system complexity (engineering tool and/or CM being aware of the capability)?
Limitations must also be clear to device vendors and more importantly they must be clear to customers buying such devices.

Some examples of scenarios to consider for devices that only support a single call:

1) If ReserveCommunicationIds is contained in such a single call, the call must theoretically be rejected with error, because there will be no subsequent calls that use the reserved ids in SetCommunicationConfiguration.
2) In a multi-CM environment, the ET or CM would have to know, which end of a connection is capable of processing multiple calls.

If, as indicated in Pauls comment, only certain commands are contained in a bundle, and remaining commands would still be processed outside of a bundle, then I see no significant reduction in implementation effort on the device side, but still increased system complexity.

My proposal: Devices shall support both single and multiple commands, which will enable them to be used in all workflows without introducing additional dependencies and complexity (and increased effort on the implementation side)

In 2022-02-08 call it was noted (as discussed before) that the command sequence diagram should be annotated (somehow) to indicate that the unbundled verify and reserve commands can be sent in any order.

Also the Reserve command should be moved higher in the sequence (before the create endpoint, etc), but that may have been done by Georg already

Integrated in specification

Review all changes in multiple calls, agreed to changes and closed issue