Complicated use case, but say you have an aggregator plugin that forks a lifecycle, and this aggregator is bound to the main lifecycle in a multimodule build. Further, say you call another plugin directly from the command line for this multimodule build, which forks a new lifecycle (like assembly:assembly). 

When the directly invoked aggregator forks, it will force the forked lifecycle phase to be run for each project in the reactor, regardless of whether this causes the bound aggregator mojo to run multiple times. When the bound aggregator executes for the first project (this will be in an inner fork, two levels removed from the main lifecycle execution) it will set the executionProject to null for the current project (which is one of the reactorProjects member instances). On the second pass, as it tries to execute the inner aggregator's forked lifecycle for the second project in the reactor, one of the reactorProjects' project.getExecutionProject() results will be null. If any of the mojos in this inner lifecycle fork requires dependency resolution, it will cause a NullPointerException in the DefaultPluginManager when it tries to resolve the dependencies for the current project.

This happened in 2.0.10-RC11 (which was the predecessor to 2.1.0-RC12, since the version was renamed while the release process was in mid-execution). It did not happen in 2.0.9, and was fixed in 2.1.0-RC12.