01
Schedule each task once
Begin with queue A and scheduled set containing A. Remove A, process it and append B then C, adding both identifiers to the scheduled set immediately. The queue is now B, C. Removing B discovers D, which has not been scheduled, so append it after C. The queue becomes C, D. At this point the scheduled set contains A, B, C and D. Marking tasks at insertion matters because another task may discover D before D reaches the front of the queue. Waiting until processing would allow that duplicate insertion.
02
Follow the shared dependency
Remove C next. Its rule points to D, but D is already scheduled, so nothing is appended. The queue remains D. Remove D; it produces no new tasks, leaving the queue empty. The processing order is A, B, C, D, with four removals and four distinct scheduled identifiers. D has two incoming references but is processed once. That difference between references and tasks is the central observation. It explains why simply counting dependency edges would not tell us how many queue removals this particular rule performs.
03
Record the boundary of the example
Use a trace with columns removed task, newly scheduled tasks and queue after the step: A gives B/C and B,C; B gives D and C,D; C gives none and D; D gives none and empty. Verify that the removal list contains each identifier once. This example assumes a fixed finite graph and successful processing. A practical scheduler would also need policies for failures, priorities and changed dependencies. Keep those questions beside the trace as extensions rather than silently treating a four-task demonstration as a complete scheduling design.