Hi Rajesh,
So, upon a certain command being handle by your aggregate, you want to load the previous state of that aggregate?
The way you've thought of it isn't the approach to take I'd say.
What you probably want to do, is make a reverting action for every event which has been applied to that aggregate after N-1.
This is also not a thing I'd do in the aggregate, but rather in the service which now publishes the described RejectCommand.
The service would in this scenario check which event have been applied to that aggregate after N-1 and create 'rejecting-commands' for each of those events.
Doing the revert/reject in one big bang would also enforce all your query side event handlers to know how to deal with such a complete revert (something I'd say is probably tough to do); one of the reasons why a finer grained solution like a propose above seems safer to me.
Hope this helps.
Cheers,
Steven