After a path is constructed, I copy the steps of the path to a path vector and hand that off to the entity, freeing up the pathfinder system to find a path for another unit.

A potential solution to this is to mark nodes as having a higher cost when they are likely to be occupied by other units, thereby causing A* to path around them. You also might want to solve this in your path-following logic rather than your path-finding logic. Getting unit avoidance to work well at the A* level is tricky and requires a lot of 4-dimensional math; path-following is a much easier place to handle the issue.

I just generate one path, hand it off to the unit that requested it, generate another for the next one, hand it off. If there are collisions along the route, it's not really the responsibility of the pathfinder to handle them. The pathfinder just finds a path. The path execution system that actually moves units is where the responsibility lies to resolve collisions, either by having one unit delay while another paths through, or by calling a local path solver (not a full path-find) to try to find a local solution to a blocked path.

Now, I suppose you could include fields in your nodes to mark them as blocked at a certain time, t. I'd probably implement this as a vector per node and incorporate the time-stamped block as part of the heuristic, to steer units around the blocked node. After a path executes a node step it would be responsible for clearing out any time blocks. Going this route just seems a bit overly complex to me, given that local collision resolution typically works well enough.

Pathfinding is plagued with the same kinds of temporal simulation complexities that physics are, with the additional burden of prediction. You probably aren't going to ever build the "perfect" pathfinder; about the best you can hope for is one that works "good enough" for your particular scenario.