Hi, thanks for posting.

Yes, this is normal behaviour. If you're making a series of rapid changes to your codebase, NCrunch can end up queuing build steps after each other. Consider the following scenario:

1. You make a code change
2. NCrunch starts building the project (Build run #1)
3. You make another code change while the project is still building
4. NCrunch wants to start building the project again for the new change, but it can't because Build run #1 is still going
5. NCrunch marks the project for "re-processing"
6. Build run #1 completes. Results are returned and merged into the UI
7. Build run #2 immediately starts
8. Build run #2 completes
9. Tests get run, etc.

The 'Execution Steps' view will record all steps performed by the engine in pursuit of the goal (completing the test run). This includes all build steps, so both of the builds above get included in this. The first build is included basically because it is an obstruction, the second because it is needed to be able to run the tests.

It's actually possible for the NCrunch engine to run multiple builds of the same project in parallel. With the workspaces, there's no logical reason this cannot happen. But we had to disable it because otherwise the engine would gobble resources with an infinite number of parallel builds whenever rapid changes were made. So now we limit the engine to one build run per project at a time.