I have 2 suggestions that I have implemented in code.

First, if you run over something in a tank or a car, it gets immediately rebuilt before the tank or car leaves the area. You can also build where the player is and trap the player. I added a check to the construct function:

  -- Check if player character, car/tank, or spidertron is blocking the ghost
  if not is_tile then
    local area = entity.bounding_box
    local blocking_entities = entity.surface.find_entities_filtered({
      area = area,
      type = { "character", "car", "spider-vehicle" }
    })

Second, I added a sort to the scan function so that closet things happen first:

    local entities = surface.find_entities_filtered(filter_params)

    table.sort(entities, function(a, b)
      local dx_a = a.position.x - position.x
      local dy_a = a.position.y - position.y
      local dist_a_sq = dx_a * dx_a + dy_a * dy_a

      local dx_b = b.position.x - position.x
      local dy_b = b.position.y - position.y
      local dist_b_sq = dx_b * dx_b + dy_b * dy_b

      return dist_a_sq < dist_b_sq
    end)

Thanks for these. Both made it into 1.1.4, although I changed a few things from your original suggestions.

The blocking check is still there, but I narrowed it down. I removed spider vehicles from the filter since spidertrons can walk over buildings. Blocking them would only prevent legitimate building without actually stopping the trap case. I also skip tile ghosts entirely since a tile can't box anything in.

The check only runs during construction, not during deconstruction, upgrades, or proxies, so there's no extra cost on those paths.

The tank case you described was a good catch and I hadn't accounted for it. A tank can break through a wall, then the mod rebuilds the wall under it before the tank has moved off the tile, leaving it stuck against the wall it just destroyed.

I also went with the sorting change. At first I thought the engine's return order might be some optimized traversal that I'd be better off leaving alone, but it turns out it's just chunk iteration order. That's why it can look random from the player's perspective.

The important part isn't really the visual ordering, though. In non-instant mode the mod only processes one entity per scan, so the order directly affects what gets built. In instant mode it matters when you run out of items partway through a scan, since the order determines which entities get built before the inventory is empty. Nearest-first makes sense in both cases.

I made it a per-player setting, enabled by default, instead of forcing it on everyone. That way anyone who prefers the old behavior can keep it, and disabling it doesn't add any extra work.

Good catches. And I appreciate that you actually wrote code to test this instead of just filing a feature request.