I think you're confusing the 2 "after" methods available @ restore:
- after_execute(). It belongs to the restore step and it's executed once all the process_xxx() methods in the step have finished to process the defined paths. I't useful for doing jobs related with one instance of a activity (restoring files, sorting, remapping parentchild relations...). The whole restore steps API is available - get_mapping() and some more. You cannot assume that other parts of the backup have been restored already. Other general APIs (course, sections, grades, enrolments... should not be used at this stage).
- after_restore(). It belongs to the restore task and it's executed once the whole restore process has ended. It's useful doing jobs related with different instances of activities, or at course level, or conditional stuff. The whole taks API (not the steps one) is available - get_courseid()... and few more. You can assume that other parts of the backup have been restored already. Other general APIs (course, sections, grades, enrolments... can be used at this stage).
In general... I'd say that only after_execute() should be used when restoring a "normal" activity. No matter of that, if there are dependencies between the information being restored (module/block...) being restored and other parts of the course is when the after_restore() implementation may have sense. From memory that only happens in a couple of blocks in Moodle because they depend of information in activities. Normal activities/blocks should not need it.
Ciao