Yeah, I appreciate this is skirting dangerously close to exposing implementation details (in particular the fact that updating a block id/data, recalculating lighting, and notifying clients are three different operations which Bukkit currently conflates into one method call).

I think I see where you're going with the "structure-based writing" idea.  One thing that occurred to me was a BlockUpdateProvider interface which plugins could implement (with perhaps a couple of stock implementations provided too).  This would be an iterator-like class which provided on-demand the next block update - basically a location plus block ID and maybe block data. MassBlockUpdate could then have a setBlockProvider() method, and a runBlockUpdate() method - runBlockUpdate() would simply consume block updates from the provider, make the changes, and when finished send the necessary chunk updates to clients (relighting is still a thorny issue, though).  This could be run over more than one tick in the interest of minimising server lag.  Thoughts?

(Stock implementations of BlockUpdateProvider could be one that pulls updates from a 1-d and/or 3-d array, and one that copies existing blocks from elsewhere).