Changed the use of operations/operation to sync_steps/sync_step. This is because $op is used in the ConfigImporter to mean the operation that is currently being performed eg create field.field.some_id.

I looked a making the method calls on the ConfigImporter use the callable syntax as well... ie. $sync_steps[] = array($this, 'processConfigurations'); this didn't work because the ConfigImporter $this gets out of sync.

Do we expect/advise people to use global functions then? Which sounds like the only remaining use case for callables then no? Looks like we should remove support for that then to direct people to the right thing and avoid them doing callables with instances of objects.

Addressing #9, array('Classname', 'static_method') and some_global_function would both be fine. We could try protecting against instance methods...if (is_array($step) && is_object($step[0])) { throw new \Exception(); }
or something...

@timplunkett: re 4, the idea was not to allow removal of the crucial built-in steps which is why the pre/post steps hooks were added. Otherwise the full alter hook could be the only one and we would be done :)

All right, changes look good to me. Not entirely happy with now having 3 new hooks for this (we could just have one alter that would do the same thing?). But I don't feel strong about it. I do see the usecase of having the pre/post hooks which are safe and the alter hook which can then alter everything and knows all the *added* items are in, so we have different hooks for adding and then for possibly doing dangerous things. I don't feel strong either way.

The only thing I found a bit weird was that the example code referenced procedural functions vs. more "Drupal Eight-y" OO code. But Alex explained that the whole Batch API atm is highly procedural-focused and we've never gotten around to modernizing the code. There's some issue for this but I can't find it right now.

Otherwise, the code is nice and easy to read and well-tested. Committed and pushed to 8.x. Thanks!