It’s easy to terminate worker by interruption with interrupt() while it compiles code. Sometimes worker terminates by manual interruption at runtime, but it’s rare. New workers are created with incremented IDs beyond current maximum ID. When need arises to update codes by include() for particular sequence of workers, so that program may operate over same IDs, terminated worker provokes movement of collection of workers somewhere to the left or right along natural number axis and conflicts arise with adjacent collections of workers, which are used by other programs. Ofcourse, new workers has to be brought familiar with new functions anyway, but arithmetics around workers’ collections becomes a bit more complicated with every terminated worker.
It could be that @spawn will ease the complexity. But when range of workers used for functions, operating over shared arrays, is defined as myid():myid+N-1, is busy worker identified as busy and free of any duty collection of workers is picked up for a task? Nope, because terminated worker may be among the collection defined and ends of collection may be brought in congestion with other collections.