Possibly due to the new bounds checking, there is some weird behaviour now with replaceblocks. Create a single biome world, whereby the biome has the StoneBlock, SurfaceBlock and GroundBlock set to 0 (air), and then ReplacedBlocks:(AIR,STONE).

The image below shows how the landscape ends up generating when travelling in different directions. Note that the holes do not seem to go to bedrock (aside from when #151 occurs, in which case, there is a hole all the way from the top of the map to bedrock). Travelling north creates a lot of horizontal gaps. Travelling east creates far fewer holes with no discernible pattern. Travelling south creates a fairly regular pattern of holes. Travelling west creates a fairly regular pattern of pillars (this seems to be the inverse of travelling south).

Image:

(in this image I was also generating ore in the form of lapis blocks and added ",(LAPIS_BLOCK,SPONGE)" to ReplacedBlocks.)

Interesting issue. This does not happen on a smaller scale, for example for creating beaches by replacing dirt to sand.

Found the bug: Minecraft has an optimization for ChunkSections (16x16x16 blocks) filled with only air: they have a null ChunkSection stored in the Chunk. TC currently skips those null ChunkSections for ReplacedBlocks. When another chunk comes along and places a block in a null ChunkSection, Minecraft will initialize it.

ReplacedBlocks happens with a 8-block-offset from the chunk center. This has been done to improve resource replacing, as most resources use that offset too. This means sometimes TC encounters a null ChunkSection, sometimes a block was already placed there and the ChunkSection is filled correctly.

I'm not going to fix this bug. Even when I have a workaround for the ChunkSection, I still need to fix the lighting bugs for ReplacedBlocks, which will slow it down significantly. That's also not the purpose of ReplacedBlocks, it's not designed to add or remove blocks. You can increase BiomeHeight if you really want all that stone. 😄