The graph specification should align with the kernel fusion extension where possible. Kernel fusion previously has a stateful queue model in their extension, but got pushback due to exception safety:

• [SYCL][Doc] Add kernel fusion extension proposal intel/llvm#7098 (comment)
• [SYCL][Doc] Add kernel fusion extension proposal intel/llvm#7098 (comment)

As a result, kernel-fusion ended up with a fusion_wrapper class:

ext::codeplay::experimental::fusion_wrapper w{q};
w.start_fusion();
// queue submissions
w.complete_fusion()

To align with kernel fusion, the complementary change to graphs record & replay model would be to change
A)

ext::oneapi::experimental::command_graph graph;
q.begin_recording(graph);
// queue submissions
q.end_recording();

Into B)

ext::oneapi::experimental::command_graph graph{q};  // could pass more than one queue here?
graph.begin_recording(); 
// queue submissions
graph.end_recording();

We did consider approach B internally at Codeplay for our vendor extension, but decided against it because it could be surprising to the user - e.g it looks like something is being done to graph, but following this call to graph.begin_recording(); the behaviour of q changes dramatically as a side effect (commands are no longer submitted for execution). However, aligning with kernel fusion here and addressing the exception safety issue which also applies to graphs I think is a motivating reason to revise our design.