I reviewed P4 CreateMonitoredItems and this delayed processing of error codes is only partially mentioned, but specifically describes this delayed processing in the context of user access rights. Here's the paragraph:

"When a user adds a monitored item that the user is denied read access to, the add operation for the item shall succeed and the bad status Bad_NotReadable or Bad_UserAccessDenied shall be returned in the Publish response. This is the same behaviour for the case where the access rights are changed after the call to CreateMonitoredItem. If the access rights change to read rights, the Server shall start sending data for the MonitoredItem."

In addition, Table 66 (part 4, page 68) does show Bad_IndexRangeInvalid as an entry.

I understand your viewpoint in that a Node's type/access can change after the call to CreateMonitoredItems, so I am thinking that we should potentially allow for 2 paths:
(1) allow the call to fail in CreateMonitoredItems (per current expectation)
(2) allow the call to fail in Publish (per your suggestion)

I do think that we need to have this clarified in P4.

What are your thoughts?

Table 66 (part 4, page 68) does show Bad_IndexRangeInvalid as an entry.
But the definition for the error code is "The syntax of the index range parameter is invalid". We don't have an invalid syntax in this test.

The behaviour should be clarified in part 4.

Added related topic for clarification in part 4

Changed our mind.
The BadIndexRangeInvalid error can be returned in the CreateMonitoredItems call if the Server decides that an IndexRange is never valid.
So the CTT needs to handle both cases.

Fixed a long time ago.