Note that BackfillTasks.addTasks() assumes that the the task input is non-nil. 
BackfillReplicationSpec.MergeNewTasks will invoke MergeIncomingTaskIntoTasksNoLock, which will recursively compute the unmergeable tasks so that that unmergeable tasks can be appended to the tasksList using addTasks(). 

Consider the following scenarios:

1. There already exists a task in the VBTasksMap of the spec - say (a, b) and we have a new incoming task to be merged - say (c, d), with d > b; a < c < b. Example: (a, b) = (5, 5000) and (c, d) = (6, 5005). Now as per variable names in MergeIncomingTaskIntoTasksNoLock, subtask1 is nil and subtask2 is non-nil and MergeIncomingTaskIntoTasksNoLock is called recursively on subtask1 and subtask2. Focusing on subtask1, since there are no more tasks in the spec's VBTasksMap, it will append nil into the unmergeable tasks list, which will eventually be added to the VBTasksMap via addTasks()

2. The same as (1), but now consider c < a; a < d < b. Example: (a, b) = (5, 5000) and (c, d) = (0, 10) => here subtask2 will be nil and cause nil to be appended to vbTasks list.

Having said that, as far as I have seen so far, we do have checks to see if the task is nil when a task is read from the map to be backfilled, say in dcp_nozzle, so this isn't a big issue. But might be worth fixing this to avoid false positives in terms of tasks left when looking for tasks left to backfill (the list might be full of null spammed) and during debugging a customer issue.