The subscriptions are mainly independent - that is, it is efficient to make four at once, but from that moment on, their changes are reported individually.

Here are in general the situations that can happen - it depends on what you mean by "broken":

a) The OPC server detects a problem when obtaining the value, and it reports it using the Quality field in the VTQ (Value/Timestamp/Quality) triple, using the normal subscription mechanism. In this case, you will receive an ItemChanged notification with the quality that tells you about the problem.

b) The OPC server detects a problem when obtaining the value, and it reports it using the item-wise error (HRESULT), using the normal subscription mechanism. In this case, you will receive an ItemChanged notification with non-null Exception property that tells you about the problem.

c) The OPC server goes down, stops responding, or the communication (network etc.) between the OPC client (QuickOPC+your code) and the OPC server breaks. In this case, similarly to the case above, you will receive an ItemChanged notification with non-null Exception property that tells you about the problem.

All in all, you should always be notified when there is a problem.
I hope this helps.

Note: There is an issue in OPC DA (but not in newer OPC UA, where multiple options exist), related to your question, but not precisely the same thing. The issue is with items that do not change their value, but are newly retrieved and therefore change their timestamp. A compliant OPC server is supposed *not* to notify the client with each such new timestamp, which is usually OK for some purposes (HMI) but not OK for purposes like trending, where one would like to know about each new timestamp.