I can add clarifications to each FilterOperator to resolve in the case of an error either to False or to NULL.

The question is what happens in addition if there is a fatal error like OutOfMemory. Since the event is most likely skipped, there is no indication for such an error.
For queue overflow we insert a special event into the queue.

My proposal is to add the following clarification:
For any fatal errors like out of memory situations, the operator either evaluates to FALSE or NULL.

In addition we should not allow implicit conversions from StatusCode to integers:
Since Event fields can have a StatusCode instead of the expected DataType, a StatusCode can only be converted to an integer with an explicit conversion.

Open Question for me:
Do we want to have some additional error indication?
We have already EventQueueOverflowEventType.
Should we introduce an EventFilterEvaluationErrorEventType?

7.7.3 FilterOperator
Added following clarification:
For any fatal errors like out of memory situations, the operator either evaluates to FALSE or NULL.

5.12.1.5 Queue parameters
Added following clarification:
For any fatal error during event processing like out of memory situations, the Server should queue an SystemStatusChangeEventType event with the ServerState COMMUNICATION_FAULT and the source set to the Server Object. If there are no resources available at the time the error happens, the Server should flag an error internally until there are resources to further process Events for the MonitoredItem.

Added in
OPC 10000-4 - UA Specification Part 4 - Services 1.05.0 Draft15.docx

Needs 1.04 Errata

Agreed to changes in Virtual F2F.