The /fill, /clone, /setblock, and /testforblock commands issue an error message if any part of the target area is outside the render distance. I thought it was saying that my coordinates were outside the world limits (which should be infinite) or that I couldn't use a target area that had ungenerated chunks, so I spent a lot of time and effort forcing chunk generation and moving the player around between executing command blocks. The message is misleading and I would argue it's an error. A better message would be something like "Cannot xxx blocks outside of the currently rendered part of the world".

Original description:

Several commands, including at least /fill, /clone, /setblock, and /testforblock, sometimes incorrectly issue the message "Cannot <xxx> blocks outside of the world" when given simple absolute coordinates that definitely are within the world limits.

"<xxx>" varies with the command and can be at least "place", "test for", or "clone". It seems obvious the commands are using a common validation procedure for the coordinate arguments, and this procedure is incorrectly failing the validation. However, a given set of coordinates will succeed sometimes and fail other times, and the effect is reproducible using the following test case ON MY COMPUTER.

Steps to reproduce:
1. Create a new flat world.
2. Teleport to (0, 4, 0).
3. Enter the command: /fill ~127 ~ ~ ~127 ~ ~ dirt
Observe that the result is "1 blocks filled".
4. Enter the command /fill ~128 ~ ~ ~128 ~ ~ dirt

2. /tp 0 4 0
3. /setblock 0 3 0 gold_block (to ensure the chunk is generated)
4. /tp 480 4 0
5. /setblock 0 3 0 diamond_block
> The error message is displayed
6. /tp 416 4 0
7. /setblock 0 3 0 diamond_block
> The block is placed
8. /tp 464 4 0
9. /setblock 0 3 0 iron_block
> The block is placed
10. /tp 480 4 0
11. /setblock 0 3 0 diamond_block
> The block is placed
Notice that steps 5 and 11 are placing the same block at the same location from the same player position, but that step 5 fails while step 11 succeeds.

What I found is that once the /setblock fails, it will consistently fail until I get to within 416 blocks (26 chunks?) of the target coordinates, and once it succeeds it will consistently succeed as I move farther away until I move 4 or more chunks in one jump.

These steps might not reproduce the problem on another device. The steps may be Windows 10 specific, or even specific to my computer, though I expect other Windows 10 computers with relatively limited memory could reproduce it with specific distances that might be different from mine. The reason I say this is that I have a hunch this problem is dependent on the destination chunk being unloaded, which would vary with the amount of available memory, and it might even be dependent on the specific memory management algorithms in use, which are often platform-specific.