Good points, Luke. But as pointed above the temporary-returning-to-the-calling-test-case won't be possible with how the UI ```Dispatcher``` runs within an NUnit thread. Few more points of interests though:

1. Technically the ```PauseDurationInMs``` can be set to ```0```, in which case the pause resumes immediately after it happens (subject to how fast the ```Dispatcher``` gets around to the next message in its queue). I provided the support to pause based on prior experiences on this, please read on :)

2. Another advantage of the new command framework as compared to the one employed by ```DSS``` is that it allows ```BackgroundWorker``` threads to have chances of completing (by allowing regular operations of a ```Dispatcher```). This is a big thing because it enables a whole new category of test cases with the ability to verify values that get evaluated asynchronously. That said, evaluation workers tend to run for a little longer than ```0ms```, if there is no mechanism to put a slight pause at some points-of-interest (e.g. at the end of a complete run, between two commands, etc.), the ```Dispatcher``` will almost always out-run the evaluation ```BackgroundWorker```, resulting in test flakiness.

3. We have performance issues in Dynamo itself. The time taken to create ```DynamoController``` is slower than these ```20ms``` pauses in orders of magnitude, naturally that will slow down all test runs and thus become an ideal candidate for tuning. I won't count on us reducing these pauses to improve the test speed any time soon :)

4. Yes, the tests and all relevant evaluations are executed in somewhat 'linear flow'. Because of that, there's no issue debugging the recorded tests.

5. Another by-product of this is of course, when there's a slowdown in evaluation that causes ```BackgroundWorker``` to take more time than anticipated, the test cases would fail. These recorded tests indirectly ensures that changes we make to all components of Dynamo do not cause slowdown. Two birds, one stone :)

6. And yes, temporary-returning-to-the-calling-test-case is indeed impossible

Along with this pause-and-resume feature, the new command framework gives Dynamo the following edge over DSS:

- It enables value verification that was not possible, everything that doesn't get done on the main thread, cannot be validated. These include preview values, node-to-code results

- It enables multi-pass verification test cases to be written