this is actually quite a long time since the method was removed. Its only intent was to improve performance in some (COM) scenarios, which turned out to be untrue anyway.
In both OPC Classic and OPC UA, the "grouping" of notifications is a physical delivery concept, for efficiency in transfer. The way the notification are sent - together or separately - bears no logical meaning, has no significance. Even when we had this method, the only way the user code needed to be written is to loop through the individual notification, and process them one by one, without assuming that the fact that they were grouped means something.
If there is a relation between the incoming notifications, it needs to be based on something else (application-specific), and not on the fact whether they were physically delivered together or separately.
I therefore think that the customer's code was already fundamentally wrong, if it cannot be easily rewritten with individual notifications, and somehow relies on the existence of MultipleItemsChanged.
Please have him explain *why* he thinks he needs that first. I believe he needs to fix approach, rather than us proposing a way to restore the code back to state that was incorrect to start with.
At some point, it seems that the EasyDAClient.MultipleItemsChanged event was removed. The EasyDAClient.ItemChanged event still exists, but I have a customer who wants to receive data changes for multiple items with the handler firing a single time, rather than the event handler being fired for each item.
With the MultipleItemsChanged event no longer available, what would be the best way to accomplish this?