I don't understand what you mean by 'deallocate' on the later passes. And what do you do on the later passes if the type in the subcells of a virtual grid differ ? My guess is that you ignore such a virtual grid location except if the other type is 'empty'. The following is based on this assumption.

You might change the grid to a two-dimensional array, that makes the code a bit more readable I think

You should create a lot of helper functions that operate on the grid in an abstract way (object-oriented design would be even better, but I don't know if you know enough about that). You should have a function get_area(x,y,virtualgridsize,villagesize). x and y are the coordinates of the upper left corner, gridsize is 1,2,3,4..., villagesize could be 1,2,3,8 or for readability you could have strings like 'village', 'town'...

This function should return an error code (for example 0) if the area is partly outside of the grid so you can simply do a foreach over the gridsize when you call this function and not worry about the edge cases. If successful it should return a reference to an array of size villagesize x villagesize, with any array value corresponding to one virtual grid cell. Typical code would then look like this

foreach my $x (0..$maxx) {
  foreach my $y (..$maxy) {
    if (my $area= get_area($x,$y,virtgridsize,'town')) {
      
...
[download]

If you have that function, create another higher-level function that calls get_area() and checks if all cells belong to one type or are empty. If yes, it returns the type, otherwise -1. This function would be called get_type_of_area(x,y,virtgridsize,villagesize)

Another function would be called set_area(type,x,y,virtgridsize,villagesize), that sets all cells to type 'type'

Now build ever higher functions out of these until you have just 5 calls to some function for every pass. What you want to arrive at is that for example checks whether some x coordinate is out of bounds or the handling of the virtual grid size is handled in some low level functions that do just the right thing. The higher level functions should only get the information in an abstraction that is useful for them.

The functions I proposed are only an example. If they don't do what you need, change them. But you need to refactor your problem into easier blocks and have this kind of abstraction so that you can reuse code and not have to write the same loops with slight variations over and over again.