I think you want to review how the navigation stack works in more detail, and the actual API of nav_core, which defines the base classes for planner plugins to the navigation stack. For instance, planners are completely separate from the actual costmap updating -- writing a new planner doesn't necessarily require even touching the costmap stuff other than using the final updated costmap to score your plans. The costmaps continually update themselves based on incoming sensor data, the local planner is called at a sufficiently high rate to generate mobile base trajectories, and the global planner is called when a new goal arrives or the local planner is unable to generate a trajectory for the last generated global plan.
As for global vs. local, well, the distinction is pretty clear. A global planner takes in a 2d-goal and a current 2d state and outputs a list of poses through which the robot should move to get to the goal. A local planner takes a list of poses (presumably created by a global planner) and creates a trajectory for the robot base for the current timestep (thus it is more of a "controller" than a "planner"). A global planner could take quite a long time to generate each plan, a local planner has to be fast (cause you typically run it at 10-20hz to get smooth mobile base motions).
Thus, the current navigation stack doesn't do much in the way of "computing the change in the map to decide when to replan", basically the local planner has just enough intelligence to wiggle a little to the left or right of an obstacle that ends up moving into the planned path, and when its path is blocked you call the global planner.
This is unclear. Are you trying to rewrite the navigation stack functionality?