Specify behaviour mixing graph building mechanisms

[EwanC]

The Unification of vendor extensions PR doesn't introduce any specification wording on what happens when a user mixes the explicit graph building mechanism with the record & replay mechanism on the same modifiable graph

If a modifiable graph is being recorded to by a queue, and then the user uses explicit APIs to add nodes to the same graph before the recording has finished, is that okay? We should specify if that's valid or not.

Another possible scenario is if a modifiable graph contains nodes which have been explicitly added, and then the user goes and records more commands to it from a queue. Is that okay? I would assume so, but again we should specify explicitly in the spec.

[Bensuo]

If a modifiable graph is being recorded to by a queue, and then the user uses explicit APIs to add nodes to the same graph before the recording has finished, is that okay? We should specify if that's valid or not.

My instinct would be that this should not be allowed. It might be possible to support but it seems like it could be easily error prone for users, and I can't think of a use case where you wouldn't just use one or the other. We could revisit it in future if a use case can be demonstrated though.

I think there are also potential ordering issues, since we don't specify when nodes are actually added to the graph when recording (it could be as soon as you submit to the queue but it also could be done during end_recording. Regardless of the outcome of this issue it would be good to add a clarification for this in the spec, either specifying when it is done or confirming it is implementation defined.

Another possible scenario is if a modifiable graph contains nodes which have been explicitly added, and then the user goes and records more commands to it from a queue. Is that okay? I would assume so, but again we should specify explicitly in the spec.

I agree this is fine.

[EwanC]

Closing as this was covered by PR #4