I think that checking MNoLastEventMode here works (as this is what the handler path does). One of my longer term goals for the handler-less path however, was to avoid using MNoLastEventMode synchronization flag. Instead of checking that flag, my plan was to rely on the LastEvent being set. If SchedulerBypass is true, then we just unset it, since the lower layers take care of the ordering. If it is false, then we have to set it, since the kernel submission to the scheduler requires ordering on the SYCL layer.
The MNoLastEventMode is still used in queue_impl::wait, which is generic, so this may be a subject to future changes. The current handler-less path however updates that flag only for compatibility with the handler path.
I think there are three cases here:

1. The LastEvent is set, then we simply add the dependency
2. The LastEvent is not set - we are in the No Last Event Mode - we have to insert the barrier
3. The LastEvent is not set - nothing was submitted to this queue yet - then we might use the MEmpty flag? But probably we have to move the MEmpty.store() to after this check.

Please let me know if this thinking makes sense and if it would be possible to replace the use of the MNoLastEventMode flag here.

I believe replacing the MNoLastEventMode check with !MEmpty will get us the same behavior after moving around the assignment.

There is one scenario where we may be adding an additional barrier with in-order queue after looking deeper: If our queue timeline looks like kernel submit -> q.wait() -> graph with host task. I don't think a barrier is needed here since we have flushed the queue already. MEmpty is only set to true when the queue is initialized and is false after the first submission, so we will inject an unneeded barrier here. However, even with MNoLastEventMode, it should remain true after the wait and inject an unnecessary barrier as well. There is a queue_empty() operation we could use but it queries the UR adapter so probably has unnecessary overhead for the general case.

I think we can switch to use MEmpty since the above issue applies to both cases. Does this match your understanding of how the queue is scheduled?

Edit: I went ahead and added this suggestion.

Would it be cleaner to just return true here (and false in the other two cases)?

It may be easier to read since we see the value of the variable. Changed.

I wonder if this argument could be called something like "InsertBarrierForCommandOrdering", which would make submit_direct more generic.

I renamed to InsertBarrierForInOrderCommand since this special case only applies to in-order queues.