Resolution:
Assume the following:

In a client named /WATCH_CLIENT you set monitor_scope to /A/…

You then issue a watch on client_names.

TipcMonClientNamesSetWatch(TRUE);

In the SmartSockets API Guide, under the Description for this call it states:

“TipcMonClientNamesSetWatch sets whether this RTclient is watching the RTclient names in the current project that match the value of the Monitor_Scope option.”

Two RTclients now connect. Their names are:

/A/BAR
/B/FOO

When client /A/BAR connects to the cloud and is in the same project as /WATCH_CLIENT then the client_names watch will be triggered in /WATCH_CLIENT.

When client /B/FOO connects to the cloud and is in the same project as /WATCH_CLIENT then the client_names watch *will not* be triggered in /WATCH_CLIENT .

You now change your monitor scope in /WATCH_CLIENT to  /B/…

And issue a TipcMonClientNamesPoll(); call.

In the SmartSockets API Guide, under the Description for this call it states:

"TipcMonClientNamesPoll polls for the RTclient names in the current project that match the value of the Monitor_Scope option..."

What will be returned in the poll callback in /WATCH_CLIENT is 1 client name:
/B/FOO

Now client /A/BAR disconnects from the cloud. This will trigger the watch on client_names that was set in /WATCH_CLIENT when the monitor_scope was set to /A/…

To change the behavior of the watch on client_names in /WATCH_CLIENT to match the current monitor_scope which is /B/…  you would do:

TipcMonClientNamesSetWatch(FALSE); /* unset from /A/… */
TipcMonClientNamesSetWatch(TRUE);   /* reset to /B/… */

How monitor_scope applies to watches and polls.