I realize this is tl;dr, so I broke it into three parts. Pretend I only posted the readable ones!
1. You could probably get away with not using an extra buffer. Each object would (1) put junk all around if it's alive, (2) check to see #if blocked, (3) decide whether to be alive or not, (4) wait half a second, and (5) change state to match decision made in Step 3.
Notice Step 4! Everyone decides whether to be dead or alive next turn, but they don't change right away -- instead, they wait until everything is settled,
then change.
2. In Conway's Game of Life, diagonally adjacent cells also count as neighbors. Unfortunately, #if blocked was not meant for checking diagonals.
Option 1: Have the objects move around to check the diagonals. Each object moves off the grid, checking out its surroundings in more detail. This might be more trouble than it's worth, especially if you have a whole bunch of objects trying to do this at the same time.
Option 2: Do some stat hacking. In an editor like KevEdit, you can manually modify an object's X Step and Y Step, which are the number of spaces the object walks per cycle. Set them both to one, and the object walks southeast. Now you can use flow for southeast, cw flow for southwest, ccw flow for northeast, and opp flow for northwest -- this should work for both #put and for #if blocked. The main drawback is that the object will be constantly on the move, but this can be cancelled out by keeping the object in a loop which runs \opp flow.
Option 3: Don't care. It's not Conway's Game of Life if you don't check the diagonals, but it's still a cellular automaton, and it's impressive enough being in ZZT and all.
3. Remember that you're limited to 150 objects, which restricts the maximum size of the Game of Life grid. If this turns out to be a significant restriction, you could have the state of the game stored entirely in terrain -- for example, use green normal to represent live cells and blue fake for dead cells. Then you'd need a series of objects to walk past the terrain, counting up the number of live cells and marking cells for life/death.
The above is what I was thinking. The objects would scroll from left to right, and they would be placed such that the rightmost ones run first. Each light gray arrow would check #if blocked s to detect any living cells -- if detected, it would #give gems 1. Then the red arrow would change the current cell, depending on how many gems the player had. To mark a live cell for death, it would #put s blue normal, and to mark a dead cell for life, it would #put s green fake. The dark gray arrows would then check for life, only this time running #take gems 1. This is to make sure that the gems counter only represents the number of living cells in a 3x3 region on the grid. After the objects scan each row, they return to their original position, #change blue normal blue fake, and #change green fake green normal.
Of course, this is far from optimal (it's really slow, we actually need fewer than 7 objects per row, you could scan multiple rows at a time using more objects and multiple counters, there might be a way to remove the spaces between cells on the grid, etc...), and it might not be worth trying to optimize the system -- but this gives you an idea of what I was thinking of. On second thought, to reduce code complexity,
it might be more helpful to add more objects to the setup -- each cycle, the gray arrows check their surroundings and the red arrow marks the tile for life or death.
Binders Keepers would probably work well enough, though. Using Binders Keepers, a 20x7 grid with spaces between each tile would be 13 tiles tall and 39 wide, which consumes 140 objects and is roughly a third of the total area of the board.
